Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename gem to foreman_redhat_access #22

Open
ekohl opened this issue Apr 6, 2018 · 5 comments
Open

Rename gem to foreman_redhat_access #22

ekohl opened this issue Apr 6, 2018 · 5 comments

Comments

@ekohl
Copy link
Contributor

ekohl commented Apr 6, 2018

The foreman plugin convention is foreman_<name>. Things are easier when this convention is followed. This mostly noticeable in the code needed in the installer, but just the visual aspect and searching for plugins in directories is easier.

@lphiri
Copy link
Contributor

lphiri commented Apr 6, 2018

I would like to rename the plugin for other reasons as well, but this is a non-trivial change due to the ripple effects to downstream packaging.

@ares
Copy link
Collaborator

ares commented Apr 6, 2018

I'm not a packaging expert, but is there other problem than just adding Obsoletes definition to the spec? We needed to do similar thing when we renamed SCL. I think we should start working on that as part of transition to theforeman org. But meanwhile we can ship the plugin with current name.

@ekohl
Copy link
Contributor Author

ekohl commented Apr 6, 2018

On the packaging side you can add Obsoletes so yum automatically migrates you to the new version without human interaction. I agree this doesn't have to be a blocker, we could even already package it with the new name and right provides. That would simplify the installer work a lot, though fixing #20 would probably also be good to do before integrating it in the installer.

@lphiri
Copy link
Contributor

lphiri commented Apr 6, 2018

There is a bit of history that complicates things.
The plugin is actually 2 plugins - there is the original "access" part, which provided the ability to manage support cases in the UI etc, and the the "Insights" part.
The right thing to do is to migrate the Insights functionality to a separate gem and corresponding rpm, and I would like do this before renaming anything.

@ekohl
Copy link
Contributor Author

ekohl commented Apr 6, 2018

That's good to know and in that case we should continue with packaging as it is now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants