4:52 p.m.
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
6:54 p.m.
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson <tdawson(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
8:47 p.m.
On Sat, 4 Jun 2022 at 18:54, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson
<tdawson(a)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.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
9:13 p.m.
On 6/5/22 03:47, Stephen Smoogen wrote:
On Sat, 4 Jun 2022 at 18:54, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson <tdawson(a)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
8:24 a.m.
On Sat, Jun 4, 2022 at 21:17 Manuel Wolfshant <wolfy(a)nobugconsulting.ro>
wrote:
On 6/5/22 03:47, Stephen Smoogen wrote:
On Sat, 4 Jun 2022 at 18:54, Neal Gompa <ngompa13(a)gmail.com> wrote:
> On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson <tdawson(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
3:54 p.m.
On Sat, 2022-06-04 at 20:47 -0400, Stephen Smoogen wrote:
On Sat, 4 Jun 2022 at 18:54, Neal Gompa <ngompa13(a)gmail.com> wrote:
> On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson <tdawson(a)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,
--
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
4:06 p.m.
Once upon a time, Michel Alexandre Salim <michel(a)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.
--
Chris Adams <linux(a)cmadams.net>
4:31 p.m.
On Wed, 2022-06-08 at 15:06 -0500, Chris Adams wrote:
Once upon a time, Michel Alexandre Salim
<michel(a)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,
--
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
6:07 p.m.
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?
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
10:43 a.m.
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.
--
Andrew C. Aitchison Kendal, UK
andrew(a)aitchison.me.uk
10:51 a.m.
Once upon a time, Andrew C Aitchison <andrew(a)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.
--
Chris Adams <linux(a)cmadams.net>
11:12 a.m.
New subject: Uninstallable due to missing CRB
On Sat, Jun 4, 2022 at 3:54 PM Neal Gompa <ngompa13(a)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
6:49 a.m.
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
--
Sérgio M. B.
7:41 a.m.
On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto <sergio(a)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
8:50 a.m.
Am 13.06.22 um 13:41 schrieb Josh Boyer:
On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto
<sergio(a)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
11:12 a.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to
epel-devel-leave(a)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.fedoraproj...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
4:17 p.m.
Once upon a time, Josh Boyer <jwboyer(a)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.
--
Chris Adams <linux(a)cmadams.net>
6:58 p.m.
On Mon, Jun 13, 2022, 4:17 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Josh Boyer <jwboyer(a)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
2:15 p.m.
On Mon, Jun 13, 2022 at 4:18 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Josh Boyer <jwboyer(a)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
--
Mike Rochefort
2:20 p.m.
On Tue, Jun 14, 2022 at 2:15 PM Mike Rochefort <mroche(a)redhat.com> wrote:
On Mon, Jun 13, 2022 at 4:18 PM Chris Adams <linux(a)cmadams.net> wrote:
>
> Once upon a time, Josh Boyer <jwboyer(a)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
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
2:25 p.m.
On Tue, Jun 14, 2022 at 2:20 PM Josh Boyer <jwboyer(a)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.
--
Mike Rochefort, RHCE
Solution Architect
Red Hat NA Commercial
US Northeast - Boston
On Tue, Jun 14, 2022 at 2:20 PM Josh Boyer <jwboyer(a)redhat.com> wrote:
On Tue, Jun 14, 2022 at 2:15 PM Mike Rochefort <mroche(a)redhat.com> wrote:
>
> On Mon, Jun 13, 2022 at 4:18 PM Chris Adams <linux(a)cmadams.net> wrote:
> >
> > Once upon a time, Josh Boyer <jwboyer(a)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
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
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
Mike Rochefort, RHCE
Solution Architect
Red Hat NA Commercial
US Northeast - Boston
2:39 p.m.
On Tue, Jun 14, 2022 at 2:20 PM Josh Boyer <jwboyer(a)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.
--
Mike Rochefort
5:16 p.m.
On Mon, Jun 13, 2022 at 5:03 AM Josh Boyer <jwboyer(a)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
11:19 p.m.
On Sat, Jun 4, 2022 at 8:52 PM Troy Dawson <tdawson(a)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.
2:30 p.m.
Jun 4, 2022 4:01:42 PM Troy Dawson <tdawson(a)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
10:43 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to
epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.o...
List Guidelines:
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wi...
List Archives:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject....
Do not reply to spam on the list, report it:
https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Di...
10:54 a.m.
On Mon, 6 Jun 2022 at 10:44, Patrick Riehecky via epel-devel <
epel-devel(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to
> epel-devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.o...
>
> List Guidelines:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wi...
>
> List Archives:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject....
>
> Do not reply to spam on the list, report it:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Di...
>
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
1:23 a.m.
On Sat, Jun 4, 2022 at 3:52 PM Troy Dawson <tdawson(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
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.
--
Carl George
6:11 p.m.
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
1:21 a.m.
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson <tdawson(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
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
--
Carl George
9:33 a.m.
On Thu, Jun 16, 2022 at 10:22 PM Carl George <carl(a)redhat.com> wrote:
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson
<tdawson(a)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
9:58 a.m.
On Fri, Jun 17, 2022 at 9:33 AM Troy Dawson <tdawson(a)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
10:03 a.m.
On Fri, 2022-06-17 at 06:33 -0700, Troy Dawson wrote:
On Thu, Jun 16, 2022 at 10:22 PM Carl George <carl(a)redhat.com> wrote:
> On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson <tdawson(a)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
5:32 p.m.
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.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
4:20 p.m.
On Fri, Jun 17, 2022 at 8:33 AM Troy Dawson <tdawson(a)redhat.com> wrote:
On Thu, Jun 16, 2022 at 10:22 PM Carl George <carl(a)redhat.com> wrote:
>
> On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson <tdawson(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
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.
--
Carl George
4:41 p.m.
On Fri, Jun 17, 2022 at 1:20 PM Carl George <carl(a)redhat.com> wrote:
On Fri, Jun 17, 2022 at 8:33 AM Troy Dawson
<tdawson(a)redhat.com> wrote:
>
>
>
> On Thu, Jun 16, 2022 at 10:22 PM Carl George <carl(a)redhat.com> wrote:
>>
>> On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson <tdawson(a)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
5:59 p.m.
On Fri, Jun 17, 2022 at 1:41 PM Troy Dawson <tdawson(a)redhat.com> wrote:
On Fri, Jun 17, 2022 at 1:20 PM Carl George <carl(a)redhat.com> wrote:
> On Fri, Jun 17, 2022 at 8:33 AM Troy Dawson <tdawson(a)redhat.com> wrote:
> >
> >
> >
> > On Thu, Jun 16, 2022 at 10:22 PM Carl George <carl(a)redhat.com> wrote:
> >>
> >> On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson <tdawson(a)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
701
days inactive
714
days old
epel-devel@lists.fedoraproject.org
36 comments
15 participants
participants (15)
-
Andrew C Aitchison -
Carl George -
Chris Adams -
Gary Buhrmaster -
Josh Boyer -
Leon Fauster -
Manuel Wolfshant -
Maxwell G -
Michel Alexandre Salim -
Mike Rochefort -
Neal Gompa -
Patrick Riehecky -
Stephen Smoogen -
Sérgio Basto -
Troy Dawson