Skip creating the yum.repos.d structure on debian based systems
If you currently run "subscription-manager repos" on a debian/ubuntu system, the directory /etc/yum.repos.d/ and the file /etc/yum.repos.d/redhat.repo with only the header are created. This is confusing some debian/ubuntu users.
This patch does fix this behaviour.
The changes in init_repo_file_classes() make sense to me.
As for the rest of the changes: it looks to me that the issue that triggers the addition of the option in RepoFileBase is the fact that RepoActionInvoker unconditionally uses YumRepo. Would you please provided a trace of the call stack that leads to the usage of RepoActionInvoker on debian-based systems? I'd rather fix that, than keep using a repo type (YumRepo) that does not belong to the current system.
Sure. Thanks @pinotree for you answer.
If you run subscription-manager repos:
File "/usr/sbin/subscription-manager", line 33, in <module>
sys.exit(load_entry_point('subscription-manager==1.29.35', 'console_scripts', 'subscription-manager')())
File "/usr/lib/python3/dist-packages/subscription_manager/scripts/subscription_manager.py", line 73, in main
return managercli.ManagerCLI().main()
File "/usr/lib/python3/dist-packages/subscription_manager/managercli.py", line 92, in main
ret: Optional[int] = CLI.main(self)
File "/usr/lib/python3/dist-packages/subscription_manager/cli.py", line 197, in main
return cmd.main()
File "/usr/lib/python3/dist-packages/subscription_manager/cli_command/cli.py", line 410, in main
return_code = self._do_command()
File "/usr/lib/python3/dist-packages/subscription_manager/cli_command/repos.py", line 141, in _do_command
repos = rl.get_repos()
File "/usr/lib/python3/dist-packages/subscription_manager/repolib.py", line 222, in get_repos
yum_repo_file = YumRepoFile(options = ['skip_creating_repo'])
File "/usr/lib/python3/dist-packages/rhsm/repofile.py", line 564, in __init__
RepoFileBase.__init__(self, path, name, options)
File "/usr/lib/python3/dist-packages/rhsm/repofile.py", line 371, in __init__
self.create()
File "/usr/lib/python3/dist-packages/rhsm/repofile.py", line 405, in create
traceback.print_stack()
So what if you replace the usage of YumRepoFile with AptRepoFile in RepoActionInvoker if HAS_DEB822 is defined? In the end, I don't see how using YumRepoFile in a debian-based would be correct, TBH...
Any thoughts on this PR @ptoscano ?
One question I have is: on a Debian system without this patch, what do you get when running subscription-manager repos?
/etc/yum.repos.d and a file red hat.repo containing the header.
Just to add - if you have rpm-repos in your Content View and run "subscription-manager repos", you might end up with repositories in redhat.repo causing other issues like breaking the package-profile-upload to katello
Can you run the tests @ptoscano ?
@jirihnidek Can you maybe give some feedback / start the tests?
@sbernhard I'm just testing/reviewing this PR.
Thanks for the PR. The file
/var/lib/rhsm/repo_server_val/redhat.repois still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.
Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.
Thanks for the PR. The file
/var/lib/rhsm/repo_server_val/redhat.repois still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.
Hmm, the code is wild. The file /var/lib/rhsm/repo_server_val/redhat.repo is still needed as "internal storage", but I would try to rename it to something like /var/lib/rhsm/repo_server_val/rhsm.sources to not look like an alien from Red Hat world. Thoughts?
Thanks for the PR. The file
/var/lib/rhsm/repo_server_val/redhat.repois still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.
Hmm, the code is wild. The file
/var/lib/rhsm/repo_server_val/redhat.repois still needed as "internal storage", but I would try to rename it to something like/var/lib/rhsm/repo_server_val/rhsm.sourcesto not look like an alien from Red Hat world. Thoughts?
Make sense in general. Maybe "a lot of things" need to be adapted because of tests etc. Should we rename this in a separete PR?
Thanks for the PR. The file
/var/lib/rhsm/repo_server_val/redhat.repois still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.
Hmm, the code is wild. The file
/var/lib/rhsm/repo_server_val/redhat.repois still needed as "internal storage", but I would try to rename it to something like/var/lib/rhsm/repo_server_val/rhsm.sourcesto not look like an alien from Red Hat world. Thoughts?Make sense in general. Maybe "a lot of things" need to be adapted because of tests etc. Should we rename this in a separete PR?
You are right. We can do that in another PR.
Thanks for the PR. The file
/var/lib/rhsm/repo_server_val/redhat.repois still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.
Hmm, the code is wild. The file
/var/lib/rhsm/repo_server_val/redhat.repois still needed as "internal storage", but I would try to rename it to something like/var/lib/rhsm/repo_server_val/rhsm.sourcesto not look like an alien from Red Hat world. Thoughts?Make sense in general. Maybe "a lot of things" need to be adapted because of tests etc. Should we rename this in a separete PR?
You are right. We can do that in another PR.
Is there something missing for this PR?
@jirihnidek / @ptoscano Any update for this?