RPM names do not match their contents - recreating issue

Creating new issue as the previous issue(RPM names do not match their contents) was closed.

Do we have any update on this?

Best Regards,
Akshat

Hello, thanks for the follow up. I've asked for an update on the internal discussion this morning. While this current issue impacts your workflow, there are some valid concerns that the potential for breaking something for a larger audience is high. I'll let you know as I get further updates.

Hello @Michael_Madden,

Please let me know if there was any further discussion on this.

Best Regards,
Akshat

Hi,

Any update on this?

@Michael_Madden

Do we have any update on this?

Best Regards,
Akshat

@jordansissel @Michael_Madden

Will this issue be fixed anytime soon? Is there any plan for this enhancement?

Best Regards,
Akshat

Hi Akshat, thanks for the reaching out. The internal discussion for this topic was never 100% resolved. I'll reach out again internally, and see if we can draw a conclusion.

I believe my earlier comment is still valid, but I'll double check.

There are some valid concerns that the potential for breaking something for a larger audience is high.

Thanks.
Michael

Thanks again for reaching out. Our internal discussion has been concluded, and we agree that the RPM names do deviate from the standard. However, the risk associated with breaking things for a larger audience outweighs any reward from an update.

  1. The current RPM names work fine for rpm/yum/dnf installations.
  2. A workaround has been provided.

Please let us know if you have any questions.

Thanks for your response.

Since we are also asked to change the RPM names for all elastic stack components by our customers, we would like to know what might be the potential risk involved in changing the RPM names?

Best Regards,
Akshat

@Michael_Madden could you please let us know about the risks that might be involved with this change? We'll have to plan our work based on it.

Best Regards,
Akshat

Hello,

Thanks for reaching out. Our concerns revolve around how small, subtle changes often cause bigger issues. Here's an example where a small change in packaging Elasticsearch caused bigger issues.

Our packages are working internally and externally for the vast majority of our customers who use rpm, yum, dnf, apt, etc. There's a significant risk involved with introducing a change that would potentially address an issue for a small audience while likely creating new issues for a broader audience.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.