When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it.
The more I think about it, the more I think we shouldn't auto-enable the crb repo for epel8 and epel9. Here are my reasons why.
1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation.
2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't own.
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. But I also wanted to get others' thoughts before I close the bug and pull request.
What do others think?
Troy
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson tdawson@redhat.com wrote:
When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it.
The more I think about it, the more I think we shouldn't auto-enable the crb repo for epel8 and epel9. Here are my reasons why.
1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation.
2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't own.
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. But I also wanted to get others' thoughts before I close the bug and pull request.
What do others think?
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
I get variations of these two examples at least *once a month*. Sometimes even filed as Bugzilla reports.
It takes time away from me doing normal work. I can easily imagine other contributors having similar burdens. For me, this is absolutely an annoying issue that creates enough overhead to be worth fixing.
Once you get to this level, "crb isn't an epel repo" and "we are taking the choice away from users" is silly, because we absolutely depend on crb being enabled and users don't know how we cross into RHEL repos for dependencies. Heck, many packagers building for EPEL don't. Even worse, some RHEL folks don't realize how difficult it is to use RHEL without CRB.
The worst thing that could happen with auto-enabling is that it fails to run. We can easily just put some output when it fails to tell users that CRB/PowerTools could not be auto-enabled and for users to ensure it's enabled. But *not* attempting to auto-enable it means we accept that RHEL's bad choices on this are impossible to work around. It would be more tolerable if CentOS Stream had CRB content available by default like how CentOS Linux 7 has the content from the RHEL 7 optional channel available by default. Sadly, every attempt to make that happen has failed. Thus, CentOS Stream and RHEL clones (which are effectively clones of CentOS Stream) don't do it, so we have a usability problem that causes pain for contributors and users.
To be crystal clear, I would like this fixed for at least the majority of cases and gracefully fail when it can't be fixed.
On Sat, 4 Jun 2022 at 18:54, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson tdawson@redhat.com wrote:
When I first created the EPEL issue to auto-enable crb repo[1] I was
only thinking of CAN we do it. I wasn't thinking SHOULD we do it.
We've come to the point that we actually can do it. But before we go
down that road, I wanted to take a step back and ask, should we do it.
The more I think about it, the more I think we shouldn't auto-enable the
crb repo for epel8 and epel9. Here are my reasons why.
1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs /
pings / emails about epel packages not being installable. I think on average about 2 a month.
With epel being in fedora-docs, and with Carl's re-write of how to
enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year.
In short, I believe the documentation is better, and easier to find,
allowing people to enable crb on their own, without automation.
2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't
own.
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios
where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many
odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I could go into more explanation on each of those things, but in the
end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9.
But I also wanted to get others' thoughts before I close the bug and
pull request.
What do others think?
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
To be crystal clear, I would like this fixed for at least the majority of cases and gracefully fail when it can't be fixed.
The issue is going to be that an RPM which changes outside subscriptions will probably be an auditable finding for a lot of sites. It is one of the reasons this has been considered bad form in the past and would probably cause a lot of requests that it be made optional, removed, OR epel black listed. It doesn't matter if we all think that would be a silly finding, changes like this are considered security issues at various sites especially if for the last 15 years, epel-release has not done something like that and so had been 'approved' for use.
At best I could see an optional side package `epel-release-enable-other-repo` or some similar name which just has these changes and is not pulled in by default and requires epel-release. Thus you could tell people to install `epel-release-enable-crb` and would get packages and if people have reports of broken packages you tell them to install this which will do the correct repo changes.
On 6/5/22 03:47, Stephen Smoogen wrote:
On Sat, 4 Jun 2022 at 18:54, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson <tdawson@redhat.com> wrote: > > When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. > We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it. > > The more I think about it, the more I think we shouldn't auto-enable the crb repo for epel8 and epel9. Here are my reasons why. > > 1 - The need to auto-enable crb isn't as big as it was before. > At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. > With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. > In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation. > > 2 - crb isn't an epel repo > We really shouldn't be messing with other repo's that we, epel, don't own. > > 3 - We are taking the choice away from users > After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb. > > 4 - All the many small side cases. > auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts. > > I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. > But I also wanted to get others' thoughts before I close the bug and pull request. > > What do others think? > Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies. To be crystal clear, I would like this fixed for at least the majority of cases and gracefully fail when it can't be fixed.
The issue is going to be that an RPM which changes outside subscriptions will probably be an auditable finding for a lot of sites. It is one of the reasons this has been considered bad form in the past and would probably cause a lot of requests that it be made optional, removed, OR epel black listed. It doesn't matter if we all think that would be a silly finding, changes like this are considered security issues at various sites especially if for the last 15 years, epel-release has not done something like that and so had been 'approved' for use.
At best I could see an optional side package `epel-release-enable-other-repo` or some similar name which just has these changes and is not pulled in by default and requires epel-release. Thus you could tell people to install `epel-release-enable-crb` and would get packages and if people have reports of broken packages you tell them to install this which will do the correct repo changes.
I really do not want to bash anyone but for _ages_ and I really mean a long long time, Ubuntu and Debian know how to be friendly and fail gracefully, suggesting the exact command that must be used when a package fails to get installed because it is not found. It's not like it is so hard to tell the user to run "dnfconfig-manager --set-enabled $whateverrepoisneeded" or even better continue with " Do you want me to enable it for you now ?"
wolfy
On Sat, Jun 4, 2022 at 21:17 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 6/5/22 03:47, Stephen Smoogen wrote:
On Sat, 4 Jun 2022 at 18:54, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson tdawson@redhat.com wrote:
When I first created the EPEL issue to auto-enable crb repo[1] I was
only thinking of CAN we do it. I wasn't thinking SHOULD we do it.
We've come to the point that we actually can do it. But before we go
down that road, I wanted to take a step back and ask, should we do it.
The more I think about it, the more I think we shouldn't auto-enable
the crb repo for epel8 and epel9. Here are my reasons why.
1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs /
pings / emails about epel packages not being installable. I think on average about 2 a month.
With epel being in fedora-docs, and with Carl's re-write of how to
enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year.
In short, I believe the documentation is better, and easier to find,
allowing people to enable crb on their own, without automation.
2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't
own.
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios
where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many
odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I could go into more explanation on each of those things, but in the
end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9.
But I also wanted to get others' thoughts before I close the bug and
pull request.
What do others think?
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
To be crystal clear, I would like this fixed for at least the majority of cases and gracefully fail when it can't be fixed.
The issue is going to be that an RPM which changes outside subscriptions will probably be an auditable finding for a lot of sites. It is one of the reasons this has been considered bad form in the past and would probably cause a lot of requests that it be made optional, removed, OR epel black listed. It doesn't matter if we all think that would be a silly finding, changes like this are considered security issues at various sites especially if for the last 15 years, epel-release has not done something like that and so had been 'approved' for use.
At best I could see an optional side package `epel-release-enable-other-repo` or some similar name which just has these changes and is not pulled in by default and requires epel-release. Thus you could tell people to install `epel-release-enable-crb` and would get packages and if people have reports of broken packages you tell them to install this which will do the correct repo changes.
I really do not want to bash anyone but for _ages_ and I really mean a long long time, Ubuntu and Debian know how to be friendly and fail gracefully, suggesting the exact command that must be used when a package fails to get installed because it is not found. It's not like it is so hard to tell the user to run "dnf config-manager --set-enabled $whateverrepoisneeded" or even better continue with " Do you want me to enable it for you now ?"
That is built into how deb and apt are written versus rpm. Doing out put like this in rpm’s breaks a lot of automation which is built around the idea that rpm are not saying things like that.
wolfy _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, 2022-06-04 at 20:47 -0400, Stephen Smoogen wrote:
On Sat, 4 Jun 2022 at 18:54, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson tdawson@redhat.com wrote:
When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it.
The more I think about it, the more I think we shouldn't auto- enable the crb repo for epel8 and epel9. Here are my reasons why.
1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation.
2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't own.
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. But I also wanted to get others' thoughts before I close the bug and pull request.
What do others think?
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
To be crystal clear, I would like this fixed for at least the majority of cases and gracefully fail when it can't be fixed.
The issue is going to be that an RPM which changes outside subscriptions will probably be an auditable finding for a lot of sites. It is one of the reasons this has been considered bad form in the past and would probably cause a lot of requests that it be made optional, removed, OR epel black listed. It doesn't matter if we all think that would be a silly finding, changes like this are considered security issues at various sites especially if for the last 15 years, epel-release has not done something like that and so had been 'approved' for use.
At best I could see an optional side package `epel-release-enable- other-repo` or some similar name which just has these changes and is not pulled in by default and requires epel-release. Thus you could tell people to install `epel-release-enable-crb` and would get packages and if people have reports of broken packages you tell them to install this which will do the correct repo changes.
This won't be ready until EPEL 10 or even 11, but one thing I've discussed with the DNF maintainer is the possibility of having something like /etc/yum.repos.d/reponame.repo.d/ where you can drop overrides, similar to how you can drop overrides for systemd unit files.
That would allow epel-release to just ship an override for crb.repo that toggles enabled=1, without messing with config files (which I hate, because that means newer crb.repo changes won't be picked up).
Best,
Once upon a time, Michel Alexandre Salim michel@michel-slm.name said:
This won't be ready until EPEL 10 or even 11, but one thing I've discussed with the DNF maintainer is the possibility of having something like /etc/yum.repos.d/reponame.repo.d/ where you can drop overrides, similar to how you can drop overrides for systemd unit files.
I've wanted (and suggested) something like this for ages, for a different reason: ability to drop-in local mirror configs, again without modifying the RPM-packaged config.
On Wed, 2022-06-08 at 15:06 -0500, Chris Adams wrote:
Once upon a time, Michel Alexandre Salim michel@michel-slm.name said:
This won't be ready until EPEL 10 or even 11, but one thing I've discussed with the DNF maintainer is the possibility of having something like /etc/yum.repos.d/reponame.repo.d/ where you can drop overrides, similar to how you can drop overrides for systemd unit files.
I've wanted (and suggested) something like this for ages, for a different reason: ability to drop-in local mirror configs, again without modifying the RPM-packaged config.
Nice! Yeah, there seems to be multiple use cases for this - come to think of it, we could use your use case in some of our internal systems too.
I'll bring it up in our internal roadmap planning and try and allocate some time for this for the next few months.
Best,
On Wednesday, June 8, 2022 2:54:51 PM CDT Michel Alexandre Salim wrote:
without messing with config files (which I hate, because that means newer crb.repo changes won't be picked up).
I thought files marked `%config(noreplace)` don't get updated automatically even if the user didn't modify it all. Am I missing something or are we talking about different things?
On Wed, 8 Jun 2022, Maxwell G via epel-devel wrote:
On Wednesday, June 8, 2022 2:54:51 PM CDT Michel Alexandre Salim wrote:
without messing with config files (which I hate, because that means newer crb.repo changes won't be picked up).
I thought files marked `%config(noreplace)` don't get updated automatically even if the user didn't modify it all. Am I missing something or are we talking about different things?
My understanding is that those files *do* get updated if they have not been modified.
This new idea will let you make a change to the config without blocking updates from making non-conflicting changes.
Once upon a time, Andrew C Aitchison andrew@aitchison.me.uk said:
On Wed, 8 Jun 2022, Maxwell G via epel-devel wrote:
On Wednesday, June 8, 2022 2:54:51 PM CDT Michel Alexandre Salim wrote:
without messing with config files (which I hate, because that means newer crb.repo changes won't be picked up).
I thought files marked `%config(noreplace)` don't get updated automatically even if the user didn't modify it all. Am I missing something or are we talking about different things?
My understanding is that those files *do* get updated if they have not been modified.
That's correct - unmodified files will still be updated by RPM.
This new idea will let you make a change to the config without blocking updates from making non-conflicting changes.
This would even be good to use for enabling/disabling repos, again so that a URL change or such would still be applied.
Long term, it might be ideal to treat the RPM-distributed repo files as read-only and move them to something like /usr/share/yum.repos.d, with only local changes (enable/disable, exclude, alternate mirror/baseurl) in /etc/yum.repos.d.
On Sat, Jun 4, 2022 at 3:54 PM Neal Gompa ngompa13@gmail.com wrote:
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
I get variations of these two examples at least *once a month*. Sometimes even filed as Bugzilla reports.
Neal, out of all the discussions for and against, this is the most troubling to me. This is the reason I opened the issue in the first place. I had a pain point, I wanted it fixed. It took a while before we figured out how to turn on crb. After we figured it out, I looked back, and noticed that I had only had one bugzilla's, emails or pings about uninstallable packages, due to missing CRB. One in six months. I used to have at least two per month. So, I assumed something happened, and that would have been the documentation got better.
But if all my bugzilla's, emails and pings just went to you. That's not good.
Can you look through your past couple of months and see if there is a trend that the "pings" are coming from certain places. I'm really curious if we can bring the number of those down by getting better documentation in key places. If you don't feel comfortable sending that to the list, feel free to send it to me directly.
If there are others that are also getting pinged, emailed, and/or bugzilla bugs due to uninstallable packages because of missing CRB, feel free to send those to this email, or me personally.
Thanks Troy
On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
if epel use crb to build some package, crb should be enabled when we install epel repo, yes , that is my opinion
On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto sergio@serjux.com wrote:
On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
if epel use crb to build some package, crb should be enabled when we install epel repo, yes , that is my opinion
If the dependency is only needed at build time, which is what CRB content is intended for, then there is no reason to default to having CRB enabled because nothing will be installed from CRB anyway. The issue that people are running into is that EPEL packages have developed *runtime* dependencies on CRB content. For a subset of users, that is probably fine. However, if a package needs something at runtime it would be better to first inquire about putting that dependency in BaseOS or AppStream rather than just blindly using it from CRB.
josh
Am 13.06.22 um 13:41 schrieb Josh Boyer:
On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto sergio@serjux.com wrote:
On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
if epel use crb to build some package, crb should be enabled when we install epel repo, yes , that is my opinion
If the dependency is only needed at build time, which is what CRB content is intended for, then there is no reason to default to having CRB enabled because nothing will be installed from CRB anyway. The issue that people are running into is that EPEL packages have developed *runtime* dependencies on CRB content. For a subset of users, that is probably fine. However, if a package needs something at runtime it would be better to first inquire about putting that dependency in BaseOS or AppStream rather than just blindly using it from CRB.
Not sure if there is a misconception but crb repo has all kind of packages also runtime ones. The concept that RH is applying against crb is; supported or not supported period. Everthing else would mean that RH should move everything without -devel in %{NAME} into appstream or baseos.
Example (powertools aka crb):
#repoquery --repoid=powertools ladspa Last metadata expiration check: 1 day, 1:43:56 ago on Sun Jun 12 13:02:39 2022. ladspa-0:1.13-20.el8.x86_64
# rpm -ev --test ladspa.x86_64 error: Failed dependencies: ladspa is needed by (installed) rubberband-1.9.0-1.el8.x86_64
# repoquery --repoid=epel rubberband Last metadata expiration check: 1 day, 1:44:41 ago on Sun Jun 12 13:02:40 2022. rubberband-0:1.9.0-1.el8.x86_64
# repoquery --repoid=powertools ladspa-devel Last metadata expiration check: 1 day, 1:46:06 ago on Sun Jun 12 13:02:39 2022. ladspa-devel-0:1.13-20.el8.i686 ladspa-devel-0:1.13-20.el8.x86_64
-- Leon
On Mon, 2022-06-13 at 07:41 -0400, Josh Boyer wrote:
On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto sergio@serjux.com wrote:
On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:
Let me start with examples that I get *regularly*: Pagure fails to install from EPEL on RHEL/CentOS/Alma/etc. because python3- markdown is not available. KDE Plasma fails to install because of a mass of missing dependencies.
if epel use crb to build some package, crb should be enabled when we install epel repo, yes , that is my opinion
If the dependency is only needed at build time, which is what CRB content is intended for, then there is no reason to default to having CRB enabled because nothing will be installed from CRB anyway. The issue that people are running into is that EPEL packages have developed *runtime* dependencies on CRB content. For a subset of users, that is probably fine. However, if a package needs something at runtime it would be better to first inquire about putting that dependency in BaseOS or AppStream rather than just blindly using it from CRB.
at least [1] we should be add to BaseOS or AppStream
[1] aspell.x86_64 12:0.60.8-8.el9 @crb poppler-qt5.x86_64 21.01.0-12.el9 @crb python3-markdown
I got the results running `dnf --disablerepo=crb list extras`
josh _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Once upon a time, Josh Boyer jwboyer@redhat.com said:
If the dependency is only needed at build time, which is what CRB content is intended for
If that's the intent, then it's not implemented correctly. For example, there are well over 100 perl modules in CRB 9. They may only be used _by Red Hat_ in building, but they are not exclusively build-time packages by a long shot.
On Mon, Jun 13, 2022, 4:17 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Josh Boyer jwboyer@redhat.com said:
If the dependency is only needed at build time, which is what CRB content is intended for
If that's the intent, then it's not implemented correctly. For example, there are well over 100 perl modules in CRB 9. They may only be used _by Red Hat_ in building, but they are not exclusively build-time packages by a long shot.
I know. I'm actually looking at squaring this in one way or another, but whatever that results in doesn't change that content in CRB will have different considerations to take into account than other repos. The same has always been true of RHEL 7 Optional as well, so it's not a new dynamic.
I also know most of those considerations don't matter to users or EPEL packagers, but I'm trying to avoid surprise in the long run.
josh
On Mon, Jun 13, 2022 at 4:18 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Josh Boyer jwboyer@redhat.com said:
If the dependency is only needed at build time, which is what CRB content is intended for
If that's the intent, then it's not implemented correctly. For example, there are well over 100 perl modules in CRB 9. They may only be used _by Red Hat_ in building, but they are not exclusively build-time packages by a long shot.
If it helps, I've updated my CRB scanner and the results (hopefully it's accurate) for seeing what EPEL packages depend on CRB packages (via "dnf rq --whatdepends <crb_package>") for both EL8 and EL9. These were run against RHEL 8 and 9 repositories with EPEL (so no EPEL Next). I don't believe it'll catch everything (such as things in epel-modular), but it could be a decent starting point for review. Would also be useful to know if this methodology is flawed and inaccurate.
https://gitlab.com/omenos/crb-depends
On Tue, Jun 14, 2022 at 2:15 PM Mike Rochefort mroche@redhat.com wrote:
On Mon, Jun 13, 2022 at 4:18 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Josh Boyer jwboyer@redhat.com said:
If the dependency is only needed at build time, which is what CRB content is intended for
If that's the intent, then it's not implemented correctly. For example, there are well over 100 perl modules in CRB 9. They may only be used _by Red Hat_ in building, but they are not exclusively build-time packages by a long shot.
If it helps, I've updated my CRB scanner and the results (hopefully it's accurate) for seeing what EPEL packages depend on CRB packages (via "dnf rq --whatdepends <crb_package>") for both EL8 and EL9. These were run against RHEL 8 and 9 repositories with EPEL (so no EPEL Next). I don't believe it'll catch everything (such as things in epel-modular), but it could be a decent starting point for review. Would also be useful to know if this methodology is flawed and inaccurate.
Not fully sure I understand the results, but this looks promising. Thanks for providing it!
One thing I caught on initial glance, I think it's getting confused on multilib. For example, from: https://gitlab.com/omenos/crb-depends/-/blob/main/el9/FINAL_EPEL.json
"gvfs.i686": [ "lutris-0:0.5.10.1-1.el9.x86_64" ],
That seems to be highlighting that lutris.x86_64 depends on gvfs.i686. I don't think that's actually the case, because gvfs.x86_64 is shipped in AppStream and should satisfy the dependency for lutris.x86_64 in EPEL.
josh
On Tue, Jun 14, 2022 at 2:20 PM Josh Boyer jwboyer@redhat.com wrote:
One thing I caught on initial glance, I think it's getting confused on multilib.
That seems to be highlighting that lutris.x86_64 depends on gvfs.i686. I don't think that's actually the case, because gvfs.x86_64 is shipped in AppStream and should satisfy the dependency for lutris.x86_64 in EPEL.
The multilib aspect is definitely the biggest quirk and I don't know the best approach besides just outright removing i686 CRB packages from the results.
On Tue, Jun 14, 2022 at 2:20 PM Josh Boyer jwboyer@redhat.com wrote:
Not fully sure I understand the results, but this looks promising.
To clarify, the FINAL_EPEL.json files contain CRB packages as the keys and their arrays are packages from EPEL that depend on them.
For for example:
"poppler-qt5.x86_64": [ "kf5-kfilemetadata-0:5.90.0-1.el9.x86_64", "kile-0:2.9.93-7.el9.x86_64", "okular-part-0:21.04.2-2.el9.x86_64", "qpdfview-qt5-0:0.4.18-9.el9.x86_64" ],
"poppler-qt5.x86_64" is the CRB package, and the contents are the EPEL packages that will either require/recommend/etc it at their install time. At least I'm pretty sure that's what "--whatdepends" means.
On Mon, Jun 13, 2022 at 5:03 AM Josh Boyer jwboyer@redhat.com wrote:
However, if a package needs something at runtime it would be better to first inquire about putting that dependency in BaseOS or AppStream rather than just blindly using it from CRB.
My first attempt as requesting a critical runtime CRB package be put into AppStream: poppler-qt5 https://bugzilla.redhat.com/show_bug.cgi?id=2096452 https://bugzilla.redhat.com/show_bug.cgi?id=2096451
We'll see how it goes.
Troy
On Sat, Jun 4, 2022 at 8:52 PM Troy Dawson tdawson@redhat.com wrote:
What do others think?
Almost everything *I* care to do with el eventually needs epel and/or CRB/Powertools.
I also do not think CRB/Powertools should be auto-enabled by epel (epel does not own them, and should not touch them).
And, yes, a couple of my ansible scripts do enable epel and crb/powertools in order to install packages, but that is my choice, not someone else's.
Jun 4, 2022 4:01:42 PM Troy Dawson tdawson@redhat.com:
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I will just add that both of these issues can be remedied. For my part, I have suggested edits on Troy's epel-release PR[1] to allow an opt-out mechanism and make the script more robust. Users who are knowledgeable enough to check whether the packages they use need CRB should also be able to opt out.
I think the real question is whether epel-release should be touching subscriptions/repos it doesn't own in the first place (Troy's question #2).
Another option would be to have the %post script only print a warning if CRB/Powertools isn't enabled instead of actually enabling it. This won't help with automated deployments[2], but it should catch some cases.
[1]: https://src.fedoraproject.org/rpms/epel-release/pull-request/21 [2]: With my ansible hat on, it also doesn't help that the two most popular epel roles on Ansible Galaxy don't enable CRB/Powertools, but I disgress. -- Thanks,
Maxwell G (@gotmax23) Pronouns: He/Him/His
I realize this is a bit of a pipe dream, but is there "some way" to ship a repo file from EPEL that points to the crb repo(s)? Folks not wanting it could block the package/not install weak deps. Getting the right repos is a bit tricky but I figured I'd voice the idea...
Pat
On Sat, 2022-06-04 at 13:52 -0700, Troy Dawson wrote:
When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it.
The more I think about it, the more I think we shouldn't auto-enable the crb repo for epel8 and epel9. Here are my reasons why.
1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation.
2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't own.
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. But I also wanted to get others' thoughts before I close the bug and pull request.
What do others think?
Troy
[1] - https://pagure.io/epel/issue/128 _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org... Do not reply to spam on the list, report it: https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfr...
On Mon, 6 Jun 2022 at 10:44, Patrick Riehecky via epel-devel < epel-devel@lists.fedoraproject.org> wrote:
I realize this is a bit of a pipe dream, but is there "some way" to ship a repo file from EPEL that points to the crb repo(s)? Folks not wanting it could block the package/not install weak deps. Getting the right repos is a bit tricky but I figured I'd voice the idea...
Not really. The repo may be: 1. Upstream mirror system 2. Subscription tool CDN 3. Subscription local satellite 4. Subscription local repos. 5. Other proprietary software system which keeps track of repos 6. A system may not have access to CRB/Powertools for various reasons. [This is common from lack of space or cost or 'meh'. 7. ... you get the idea that there are going to be more variations. Get 10 computer sites, and you will have 10! (328800) solutions in no time.
subscription-manager can deal with most of those variations and dnf can deal with ones where a config file already exists.
Just for the record, dealing with the above variations was a continuing problem for the repositories before EPEL (Dag and such), and for EL5 which had repos which weren't generally shipped or available. It is only with EL6 and EL7, that we as a third party had an easy time of dealing with all the parts being shipped with upstream EL.
Pat
On Sat, 2022-06-04 at 13:52 -0700, Troy Dawson wrote:
When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it.
The more I think about it, the more I think we shouldn't auto-enable the crb repo for epel8 and epel9. Here are my reasons why.
1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation.
2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't own.
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. But I also wanted to get others' thoughts before I close the bug and pull request.
What do others think?
Troy
[1] - https://pagure.io/epel/issue/128 _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_...
List Guidelines:
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_...
List Archives:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org...
Do not reply to spam on the list, report it:
https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfr...
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, Jun 4, 2022 at 3:52 PM Troy Dawson tdawson@redhat.com wrote:
When I first created the EPEL issue to auto-enable crb repo[1] I was only thinking of CAN we do it. I wasn't thinking SHOULD we do it. We've come to the point that we actually can do it. But before we go down that road, I wanted to take a step back and ask, should we do it.
The more I think about it, the more I think we shouldn't auto-enable the crb repo for epel8 and epel9. Here are my reasons why.
1 - The need to auto-enable crb isn't as big as it was before. At the time that I wrote that issue, I was getting quite alot of bugs / pings / emails about epel packages not being installable. I think on average about 2 a month. With epel being in fedora-docs, and with Carl's re-write of how to enable epel, that number has dropped significantly. I possibly still average one a month, but that's an average over a year, with most of them being last year. In short, I believe the documentation is better, and easier to find, allowing people to enable crb on their own, without automation.
2 - crb isn't an epel repo We really shouldn't be messing with other repo's that we, epel, don't own.
3 - We are taking the choice away from users After I stopped and thought about it, there are plenty of scenarios where people want epel for just one or two packages, which do not require crb.
4 - All the many small side cases. auto-enabling crb will have bugs. RHEL and it's clones are in too many odd places for us to not hit some odd use cases we didn't expect. We'd have to keep fixing the scripts.
I could go into more explanation on each of those things, but in the end, I've talked myself out of wanting to auto-enable crb for epel8 and epel9. But I also wanted to get others' thoughts before I close the bug and pull request.
What do others think?
Troy
[1] - https://pagure.io/epel/issue/128 _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
I have sympathy for the issue we are trying to solve, but I do not think it's that big a deal. Enabling crb is a documented part of setting up EPEL. Anyone having issues because crb isn't enabled failed to follow the instructions. Continuing to redirect people to the instructions will eventually result in this being common knowledge, and the instances of having to tell people about it will continue to fall. We can further reduce these instances by requesting EPEL runtime dependencies be "promoted" from crb to baseos or appstream. In the mean time, it's not that much work to copy/paste "the missing dependencies are in crb/powertools, follow the setup instructions again" to the occasional bug report.
When we were first setting up the repo definitions for CentOS Stream 9, I suggested the idea of moving the crb repo file to a separate package (centos-release-crb), with enabled=1 but not installed by default. This would allow epel-release to recommmend centos-release-crb. There was push back to this idea because there is a desire for the "enable crb" action in CentOS Stream to look roughly similar to how it works in RHEL (`dnf config-manager --set-enabled crb` and `subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms`). Maybe we can revisit this idea for CentOS Stream 10.
I'm totally top-posting, and I apologize for that.
For right now, I'm going to put my enable-crb script in epel-release, but not automatically run it in a %post script or anything. The debate about putting it in a post script, or a separate package, can go on independently of the script.
This does a few things. - give people a single, easy to remember way to enable crb -- Right now if you install anything but RHEL you might remember "dnf install epel-release" but then you forget what the dnf command is to enable a repo, and you might forget if it's crb or powertools. -- It will make scripting easier because you just have one command that will work across all RHEL compatibles.
- gives the script a chance to find all the corner cases -- It's worked on everything I've tried thus far, but I'm sure there are some corner cases or two where the script doesn't work.
I was thinking of it being /usr/bin/enable-crb /usr/bin/epel-enable-crb (a link to enable-crb)
Thoughts?
Troy
https://pagure.io/epel/issue/128 https://src.fedoraproject.org/rpms/epel-release/pull-request/21
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson tdawson@redhat.com wrote:
I'm totally top-posting, and I apologize for that.
For right now, I'm going to put my enable-crb script in epel-release, but not automatically run it in a %post script or anything. The debate about putting it in a post script, or a separate package, can go on independently of the script.
This does a few things.
- give people a single, easy to remember way to enable crb
-- Right now if you install anything but RHEL you might remember "dnf install epel-release" but then you forget what the dnf command is to enable a repo, and you might forget if it's crb or powertools. -- It will make scripting easier because you just have one command that will work across all RHEL compatibles.
- gives the script a chance to find all the corner cases
-- It's worked on everything I've tried thus far, but I'm sure there are some corner cases or two where the script doesn't work.
I was thinking of it being /usr/bin/enable-crb /usr/bin/epel-enable-crb (a link to enable-crb)
Thoughts?
Troy
https://pagure.io/epel/issue/128 https://src.fedoraproject.org/rpms/epel-release/pull-request/21 _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
I think it would be nice to be able to both enable and disable from the same script. This would come in handy when you are looking for things that don't install when crb is disabled. I don't see anything else in Fedora or RHEL that ships a command with the name crb, so how about that?
crb enable crb disable
On Thu, Jun 16, 2022 at 10:22 PM Carl George carl@redhat.com wrote:
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson tdawson@redhat.com wrote:
I'm totally top-posting, and I apologize for that.
For right now, I'm going to put my enable-crb script in epel-release,
but not automatically run it in a %post script or anything.
The debate about putting it in a post script, or a separate package, can
go on independently of the script.
This does a few things.
- give people a single, easy to remember way to enable crb
-- Right now if you install anything but RHEL you might remember "dnf
install epel-release" but then you forget what the dnf command is to enable a repo, and you might forget if it's crb or powertools.
-- It will make scripting easier because you just have one command that
will work across all RHEL compatibles.
- gives the script a chance to find all the corner cases
-- It's worked on everything I've tried thus far, but I'm sure there are
some corner cases or two where the script doesn't work.
I was thinking of it being /usr/bin/enable-crb /usr/bin/epel-enable-crb (a link to enable-crb)
Thoughts?
Troy
I think it would be nice to be able to both enable and disable from the same script. This would come in handy when you are looking for things that don't install when crb is disabled. I don't see anything else in Fedora or RHEL that ships a command with the name crb, so how about that?
crb enable crb disable
That shouldn't be too hard. I'm going to give it a shot. If that takes too long, I'll just push what I currently have for now.
I notice that you said crb-enable, crb-disable. Do you like having the name first, or the function first?
enable-crb vs crb-enable ?
either way I want to have it by itself, as well as starting with epel
epel-enable-crb vs epel-crb-enable ?
Troy
On Fri, Jun 17, 2022 at 9:33 AM Troy Dawson tdawson@redhat.com wrote:
I notice that you said crb-enable, crb-disable. Do you like having the name first, or the function first?
I'd put in a vote for "object action" like Carl denoted.
As a side note, and this is more for personal learning/clarification, is there a particular reason why RHEL systems need to use subscription-manager rather than config-manager to manage Red Hat repos? Subman is significantly slower to enable/disable a repo than config-manager, and outside of a given host not having dnf-plugins-core installed config-manager would appear to be the better solution in my eyes. On my RHEL systems I rarely touch subman post-registration in favor of config-manager; maybe there's something I'm missing about RHEL repo management or background tasks subman is doing.
-- Mike
On Fri, 2022-06-17 at 06:33 -0700, Troy Dawson wrote:
On Thu, Jun 16, 2022 at 10:22 PM Carl George carl@redhat.com wrote:
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson tdawson@redhat.com wrote:
I'm totally top-posting, and I apologize for that.
For right now, I'm going to put my enable-crb script in epel- release, but not automatically run it in a %post script or anything. The debate about putting it in a post script, or a separate package, can go on independently of the script.
This does a few things.
- give people a single, easy to remember way to enable crb
-- Right now if you install anything but RHEL you might remember "dnf install epel-release" but then you forget what the dnf command is to enable a repo, and you might forget if it's crb or powertools. -- It will make scripting easier because you just have one command that will work across all RHEL compatibles.
- gives the script a chance to find all the corner cases
-- It's worked on everything I've tried thus far, but I'm sure there are some corner cases or two where the script doesn't work.
I was thinking of it being /usr/bin/enable-crb /usr/bin/epel-enable-crb (a link to enable-crb)
Thoughts?
Troy
I think it would be nice to be able to both enable and disable from the same script. This would come in handy when you are looking for things that don't install when crb is disabled. I don't see anything else in Fedora or RHEL that ships a command with the name crb, so how about that?
crb enable crb disable
That shouldn't be too hard. I'm going to give it a shot. If that takes too long, I'll just push what I currently have for now.
I notice that you said crb-enable, crb-disable. Do you like having the name first, or the function first?
enable-crb vs crb-enable ?
either way I want to have it by itself, as well as starting with epel
epel-enable-crb vs epel-crb-enable ?
Troy
I'd be tempted to go with something like:
epel-crb-repo $action
This way any extra ideas for actions can be added easily later on. Perhaps a "check" or "status" to see if CRB is enabled/disabled/not- what-the-os-ships.
Pat
On Friday, June 17, 2022 9:03:07 AM CDT Patrick Riehecky via epel-devel wrote:
This way any extra ideas for actions can be added easily later on. Perhaps a "check" or "status" to see if CRB is enabled/disabled/not- what-the-os-ships.
+1. Having some logic to check if CRB is actually enabled would allow us to create a scriptlet for epel-release to print a warning instructing users to run `crb enable` if necessary.
On Fri, Jun 17, 2022 at 8:33 AM Troy Dawson tdawson@redhat.com wrote:
On Thu, Jun 16, 2022 at 10:22 PM Carl George carl@redhat.com wrote:
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson tdawson@redhat.com wrote:
I'm totally top-posting, and I apologize for that.
For right now, I'm going to put my enable-crb script in epel-release, but not automatically run it in a %post script or anything. The debate about putting it in a post script, or a separate package, can go on independently of the script.
This does a few things.
- give people a single, easy to remember way to enable crb
-- Right now if you install anything but RHEL you might remember "dnf install epel-release" but then you forget what the dnf command is to enable a repo, and you might forget if it's crb or powertools. -- It will make scripting easier because you just have one command that will work across all RHEL compatibles.
- gives the script a chance to find all the corner cases
-- It's worked on everything I've tried thus far, but I'm sure there are some corner cases or two where the script doesn't work.
I was thinking of it being /usr/bin/enable-crb /usr/bin/epel-enable-crb (a link to enable-crb)
Thoughts?
Troy
I think it would be nice to be able to both enable and disable from the same script. This would come in handy when you are looking for things that don't install when crb is disabled. I don't see anything else in Fedora or RHEL that ships a command with the name crb, so how about that?
crb enable crb disable
That shouldn't be too hard. I'm going to give it a shot. If that takes too long, I'll just push what I currently have for now.
I notice that you said crb-enable, crb-disable. Do you like having the name first, or the function first?
enable-crb vs crb-enable ?
either way I want to have it by itself, as well as starting with epel
epel-enable-crb vs epel-crb-enable ?
Troy
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
I was specifically suggesting /usr/bin/crb, accepting a single argument of enable or disable. I can't find anything else in Fedora or RHEL using that path.
What would be the purpose of prefixing it with "epel-"? It's not "CRB from EPEL", it's a generic script for enabling/disabling the crb repo that just happens to be included in the epel-release package.
On Fri, Jun 17, 2022 at 1:20 PM Carl George carl@redhat.com wrote:
On Fri, Jun 17, 2022 at 8:33 AM Troy Dawson tdawson@redhat.com wrote:
On Thu, Jun 16, 2022 at 10:22 PM Carl George carl@redhat.com wrote:
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson tdawson@redhat.com wrote:
I'm totally top-posting, and I apologize for that.
For right now, I'm going to put my enable-crb script in epel-release,
but not automatically run it in a %post script or anything.
The debate about putting it in a post script, or a separate package,
can go on independently of the script.
This does a few things.
- give people a single, easy to remember way to enable crb
-- Right now if you install anything but RHEL you might remember "dnf
install epel-release" but then you forget what the dnf command is to enable a repo, and you might forget if it's crb or powertools.
-- It will make scripting easier because you just have one command
that will work across all RHEL compatibles.
- gives the script a chance to find all the corner cases
-- It's worked on everything I've tried thus far, but I'm sure there
are some corner cases or two where the script doesn't work.
I was thinking of it being /usr/bin/enable-crb /usr/bin/epel-enable-crb (a link to enable-crb)
Thoughts?
Troy
I think it would be nice to be able to both enable and disable from the same script. This would come in handy when you are looking for things that don't install when crb is disabled. I don't see anything else in Fedora or RHEL that ships a command with the name crb, so how about that?
crb enable crb disable
That shouldn't be too hard. I'm going to give it a shot. If that takes too long, I'll just push what I currently have for now.
I notice that you said crb-enable, crb-disable. Do you like having the name first, or the function first?
enable-crb vs crb-enable ?
either way I want to have it by itself, as well as starting with epel
epel-enable-crb vs epel-crb-enable ?
Troy
I was specifically suggesting /usr/bin/crb, accepting a single argument of enable or disable. I can't find anything else in Fedora or RHEL using that path.
What would be the purpose of prefixing it with "epel-"? It's not "CRB from EPEL", it's a generic script for enabling/disabling the crb repo that just happens to be included in the epel-release package.
crb is as good as anything else. I'll use that, with options.
Troy
On Fri, Jun 17, 2022 at 1:41 PM Troy Dawson tdawson@redhat.com wrote:
On Fri, Jun 17, 2022 at 1:20 PM Carl George carl@redhat.com wrote:
On Fri, Jun 17, 2022 at 8:33 AM Troy Dawson tdawson@redhat.com wrote:
On Thu, Jun 16, 2022 at 10:22 PM Carl George carl@redhat.com wrote:
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson tdawson@redhat.com
wrote:
I'm totally top-posting, and I apologize for that.
For right now, I'm going to put my enable-crb script in
epel-release, but not automatically run it in a %post script or anything.
The debate about putting it in a post script, or a separate package,
can go on independently of the script.
This does a few things.
- give people a single, easy to remember way to enable crb
-- Right now if you install anything but RHEL you might remember
"dnf install epel-release" but then you forget what the dnf command is to enable a repo, and you might forget if it's crb or powertools.
-- It will make scripting easier because you just have one command
that will work across all RHEL compatibles.
- gives the script a chance to find all the corner cases
-- It's worked on everything I've tried thus far, but I'm sure there
are some corner cases or two where the script doesn't work.
I was thinking of it being /usr/bin/enable-crb /usr/bin/epel-enable-crb (a link to enable-crb)
Thoughts?
Troy
I think it would be nice to be able to both enable and disable from the same script. This would come in handy when you are looking for things that don't install when crb is disabled. I don't see anything else in Fedora or RHEL that ships a command with the name crb, so how about that?
crb enable crb disable
That shouldn't be too hard. I'm going to give it a shot. If that takes too long, I'll just push what I currently have for now.
I notice that you said crb-enable, crb-disable. Do you like having the name first, or the function first?
enable-crb vs crb-enable ?
either way I want to have it by itself, as well as starting with epel
epel-enable-crb vs epel-crb-enable ?
Troy
I was specifically suggesting /usr/bin/crb, accepting a single argument of enable or disable. I can't find anything else in Fedora or RHEL using that path.
What would be the purpose of prefixing it with "epel-"? It's not "CRB from EPEL", it's a generic script for enabling/disabling the crb repo that just happens to be included in the epel-release package.
crb is as good as anything else. I'll use that, with options.
Troy
Pull request has been updated. https://src.fedoraproject.org/rpms/epel-release/pull-request/21
The script is now called /usr/bin/crb The script can enable, disable and give the status of the crb repo. This script is NOT run during epel-release install. %post gives a recommendation to run the script.
The script has been tested on virtual machines for rhel8, rhel9, alma8, alma9, cs8 and cs9. The test enabled, disabled, and gave statuses. Works pretty good with everything I've tested.
Let me know what ya'll think.
Troy
epel-devel@lists.fedoraproject.org