Hi,
With the refocus of CentOS to Stream, i think it'd make sense to open the discussion about the missing subpackages (mainly devel ones) in the repos.
While I understand that this was part of the idea of a "pure clone" of RHEL when working with CentOS Linux, now that stream is more intended to be used by devel community and not as a pure rebuild, I think there are reasons to change this policy.
What'd be the best way to open this discussion?, is it being discussed already?, should this be a topic for the board?
Best regards,
Alfredo
On 21/01/2021 11.34, Alfredo Moralejo Alonso wrote:
Hi,
With the refocus of CentOS to Stream, i think it'd make sense to open the discussion about the missing subpackages (mainly devel ones) in the repos.
While I understand that this was part of the idea of a "pure clone" of RHEL when working with CentOS Linux, now that stream is more intended to be used by devel community and not as a pure rebuild, I think there are reasons to change this policy.
What'd be the best way to open this discussion?, is it being discussed already?, should this be a topic for the board?
Best regards,
Alfredo
Not answering your questions, but probably related: I already opened a Bug on bugzilla.redhat.com (#1915238) about the CentOS Stream "Devel" repository being empty. So the situation concerning devel subpackages is currently even worse for CentOS Stream 8 than for CentOS Linux 8.
For some reasons the bug can not be viewed by the public. I don't know why and it seems that I can not change it. Disclaimer: I have to admit that I'm not used to Bugzilla, so maybe I'm just missing the proper setting.
Best
Peter
On Thu, Jan 21, 2021 at 11:49 AM Peter Georg < peter.georg@physik.uni-regensburg.de> wrote:
On 21/01/2021 11.34, Alfredo Moralejo Alonso wrote:
Hi,
With the refocus of CentOS to Stream, i think it'd make sense to open the discussion about the missing subpackages (mainly devel ones) in the
repos.
While I understand that this was part of the idea of a "pure clone" of
RHEL
when working with CentOS Linux, now that stream is more intended to be
used
by devel community and not as a pure rebuild, I think there are reasons
to
change this policy.
What'd be the best way to open this discussion?, is it being discussed already?, should this be a topic for the board?
Best regards,
Alfredo
Not answering your questions, but probably related: I already opened a Bug on bugzilla.redhat.com (#1915238) about the CentOS Stream "Devel" repository being empty. So the situation concerning devel subpackages is currently even worse for CentOS Stream 8 than for CentOS Linux 8.
Thanks for the hint.
You are right, Devel repo is now empty for c8s making things worse.
Let's see if we can get any additional detail from the CentOS core team.
For some reasons the bug can not be viewed by the public. I don't know why and it seems that I can not change it. Disclaimer: I have to admit that I'm not used to Bugzilla, so maybe I'm just missing the proper setting.
Best
Peter _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Le 21/01/2021 à 11:59, Alfredo Moralejo Alonso a écrit :
On Thu, Jan 21, 2021 at 11:49 AM Peter Georg <peter.georg@physik.uni-regensburg.de mailto:peter.georg@physik.uni-regensburg.de> wrote:
On 21/01/2021 11.34, Alfredo Moralejo Alonso wrote: > Hi, > > With the refocus of CentOS to Stream, i think it'd make sense to open the > discussion about the missing subpackages (mainly devel ones) in the repos. > > While I understand that this was part of the idea of a "pure clone" of RHEL > when working with CentOS Linux, now that stream is more intended to be used > by devel community and not as a pure rebuild, I think there are reasons to > change this policy. > > What'd be the best way to open this discussion?, is it being discussed > already?, should this be a topic for the board? > > Best regards, > > Alfredo Not answering your questions, but probably related: I already opened a Bug on bugzilla.redhat.com <http://bugzilla.redhat.com> (#1915238) about the CentOS Stream "Devel" repository being empty. So the situation concerning devel subpackages is currently even worse for CentOS Stream 8 than for CentOS Linux 8.Thanks for the hint.
You are right, Devel repo is now empty for c8s making things worse.
Let's see if we can get any additional detail from the CentOS core team.
While missing -devel sub-packages and other missing sub-packages are likely 2 separate topics, I'd really like both of them to be addressed.
Regards, Xavier
On Thu, Jan 21, 2021 at 5:35 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
With the refocus of CentOS to Stream, i think it'd make sense to open the discussion about the missing subpackages (mainly devel ones) in the repos.
While I understand that this was part of the idea of a "pure clone" of RHEL when working with CentOS Linux, now that stream is more intended to be used by devel community and not as a pure rebuild, I think there are reasons to change this policy.
What'd be the best way to open this discussion?, is it being discussed already?, should this be a topic for the board?
This is indeed a great question and yes, we are already discussing it internally. To be quite frank, we've been discussing it for quite some time and long before the CentOS Linux announcement. There is a balance to be struck between making CentOS Stream a viable platform for ecosystem development, and faithfully representing what will become the next RHEL minor release.
To date CentOS Linux and CentOS Stream have both stuck to "we provide what RHEL provides" so that anyone consuming them gets parity with RHEL. This benefits users that have a mixed RHEL/CentOS environment, and developers targeting the next release of RHEL by using CentOS Stream because they build against what RHEL has available. It prevents them from inadvertently getting themselves into situations where an application or package may build on a CentOS flavor, but fail to run on RHEL due to missing dependencies or, less noticable, running against unsupported content.
However, we have seen, and I have personally evaluated, MANY requests for some of the unshipped packages for what are very valid reasons. By working with the CentOS team, we have slowly adjusted our default approach to these requests and we're continuing to evolve it. I will be working further with them to figure out how best to strike this balance, particularly in light of CentOS Stream 9 coming and the increased emphasis on using that directly for RHEL development.
I can promise no timelines and we have nothing concrete to share at the moment, but please know we're taking this seriously and the information the community is providing on what use cases they are trying to solve is actually critical to coming up with the right solutions. The more we know about how our users leverage our projects and products, the better we can make them. Thanks in advance for your patience.
josh
Hi,
On Thu, Jan 21, 2021 at 3:01 PM Josh Boyer jwboyer@redhat.com wrote:
On Thu, Jan 21, 2021 at 5:35 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
With the refocus of CentOS to Stream, i think it'd make sense to open
the discussion about the missing subpackages (mainly devel ones) in the repos.
While I understand that this was part of the idea of a "pure clone" of
RHEL when working with CentOS Linux, now that stream is more intended to be used by devel community and not as a pure rebuild, I think there are reasons to change this policy.
What'd be the best way to open this discussion?, is it being discussed
already?, should this be a topic for the board?
This is indeed a great question and yes, we are already discussing it internally. To be quite frank, we've been discussing it for quite some time and long before the CentOS Linux announcement. There is a balance to be struck between making CentOS Stream a viable platform for ecosystem development, and faithfully representing what will become the next RHEL minor release.
To date CentOS Linux and CentOS Stream have both stuck to "we provide what RHEL provides" so that anyone consuming them gets parity with RHEL. This benefits users that have a mixed RHEL/CentOS environment, and developers targeting the next release of RHEL by using CentOS Stream because they build against what RHEL has available. It prevents them from inadvertently getting themselves into situations where an application or package may build on a CentOS flavor, but fail to run on RHEL due to missing dependencies or, less noticable, running against unsupported content.
Putting all "unsupported" content in a separated -unsupported repo which would be disabled by default could be a suitable solution (similar to current Devel but automatically populated with unshipped content on each new build).
However, we have seen, and I have personally evaluated, MANY requests for some of the unshipped packages for what are very valid reasons. By working with the CentOS team, we have slowly adjusted our default approach to these requests and we're continuing to evolve it. I will be working further with them to figure out how best to strike this balance, particularly in light of CentOS Stream 9 coming and the increased emphasis on using that directly for RHEL development.
I can promise no timelines and we have nothing concrete to share at the moment, but please know we're taking this seriously and the information the community is providing on what use cases they are trying to solve is actually critical to coming up with the right solutions. The more we know about how our users leverage our projects and products, the better we can make them. Thanks in advance for your patience.
Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions?
Thanks for the info!
Alfredo
josh
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jan 21, 2021 at 9:57 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
On Thu, Jan 21, 2021 at 3:01 PM Josh Boyer jwboyer@redhat.com wrote:
On Thu, Jan 21, 2021 at 5:35 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
With the refocus of CentOS to Stream, i think it'd make sense to open the discussion about the missing subpackages (mainly devel ones) in the repos.
While I understand that this was part of the idea of a "pure clone" of RHEL when working with CentOS Linux, now that stream is more intended to be used by devel community and not as a pure rebuild, I think there are reasons to change this policy.
What'd be the best way to open this discussion?, is it being discussed already?, should this be a topic for the board?
This is indeed a great question and yes, we are already discussing it internally. To be quite frank, we've been discussing it for quite some time and long before the CentOS Linux announcement. There is a balance to be struck between making CentOS Stream a viable platform for ecosystem development, and faithfully representing what will become the next RHEL minor release.
To date CentOS Linux and CentOS Stream have both stuck to "we provide what RHEL provides" so that anyone consuming them gets parity with RHEL. This benefits users that have a mixed RHEL/CentOS environment, and developers targeting the next release of RHEL by using CentOS Stream because they build against what RHEL has available. It prevents them from inadvertently getting themselves into situations where an application or package may build on a CentOS flavor, but fail to run on RHEL due to missing dependencies or, less noticable, running against unsupported content.
Putting all "unsupported" content in a separated -unsupported repo which would be disabled by default could be a suitable solution (similar to current Devel but automatically populated with unshipped content on each new build).
It's not a bad suggestion, but experience shows that naming or including "unsupported" in a repo or a package name doesn't mean much. If people can install it, they will. Also, we largely did that in RHEL 7. It is called the Optional repo and the content in there is unsupported. Let's just say it was not the deterrent that was originally envisioned and led to a number of problems.
However, we have seen, and I have personally evaluated, MANY requests for some of the unshipped packages for what are very valid reasons. By working with the CentOS team, we have slowly adjusted our default approach to these requests and we're continuing to evolve it. I will be working further with them to figure out how best to strike this balance, particularly in light of CentOS Stream 9 coming and the increased emphasis on using that directly for RHEL development.
I can promise no timelines and we have nothing concrete to share at the moment, but please know we're taking this seriously and the information the community is providing on what use cases they are trying to solve is actually critical to coming up with the right solutions. The more we know about how our users leverage our projects and products, the better we can make them. Thanks in advance for your patience.
Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions?
At the moment, nothing that is public. This is larger than a bug at any rate.
Perhaps once there's a process for CentOS Stream community requests or interests that are larger in scope, someone could take the time to write up something that we can use to facilitate that discussion.
josh
On 21/01/2021 22:02, Josh Boyer wrote:
On Thu, Jan 21, 2021 at 9:57 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
<snip>
Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions?
While I'm not aware of any public discussion for this (outside of bug reports on bugs.centos.org or discussion on irc or here on this list), I was told to file bug reports for such cases on bugzilla.redhat.com
The CentOS infra team already suffers from unreleased pkgs case (irony that we built but can't consume these pkgs ourselves ...) : for the upcoming Fedora/CentOS authentication merge, there is one pkg that can't enter epel8 because of unreleased pkgs (see https://bugzilla.redhat.com/show_bug.cgi?id=1888195)
So that means that , also because it would be a problem to rebuild these in cbs.centos.org, itself consuming the official centos repos as external repositories, my only workaround was to use .. copr :/
If there is somehow a way to even unblock Fedora and CentOS team deploying solutions on top of IPA for authentication, I'd be more than happy :-)
On 21/01/2021 22.02, Josh Boyer wrote:
On Thu, Jan 21, 2021 at 9:57 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
On Thu, Jan 21, 2021 at 3:01 PM Josh Boyer jwboyer@redhat.com wrote:
On Thu, Jan 21, 2021 at 5:35 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
With the refocus of CentOS to Stream, i think it'd make sense to open the discussion about the missing subpackages (mainly devel ones) in the repos.
While I understand that this was part of the idea of a "pure clone" of RHEL when working with CentOS Linux, now that stream is more intended to be used by devel community and not as a pure rebuild, I think there are reasons to change this policy.
What'd be the best way to open this discussion?, is it being discussed already?, should this be a topic for the board?
This is indeed a great question and yes, we are already discussing it internally. To be quite frank, we've been discussing it for quite some time and long before the CentOS Linux announcement. There is a balance to be struck between making CentOS Stream a viable platform for ecosystem development, and faithfully representing what will become the next RHEL minor release.
To date CentOS Linux and CentOS Stream have both stuck to "we provide what RHEL provides" so that anyone consuming them gets parity with RHEL. This benefits users that have a mixed RHEL/CentOS environment, and developers targeting the next release of RHEL by using CentOS Stream because they build against what RHEL has available. It prevents them from inadvertently getting themselves into situations where an application or package may build on a CentOS flavor, but fail to run on RHEL due to missing dependencies or, less noticable, running against unsupported content.
Putting all "unsupported" content in a separated -unsupported repo which would be disabled by default could be a suitable solution (similar to current Devel but automatically populated with unshipped content on each new build).
It's not a bad suggestion, but experience shows that naming or including "unsupported" in a repo or a package name doesn't mean much. If people can install it, they will. Also, we largely did that in RHEL 7. It is called the Optional repo and the content in there is unsupported. Let's just say it was not the deterrent that was originally envisioned and led to a number of problems.
However, we have seen, and I have personally evaluated, MANY requests for some of the unshipped packages for what are very valid reasons. By working with the CentOS team, we have slowly adjusted our default approach to these requests and we're continuing to evolve it. I will be working further with them to figure out how best to strike this balance, particularly in light of CentOS Stream 9 coming and the increased emphasis on using that directly for RHEL development.
I can promise no timelines and we have nothing concrete to share at the moment, but please know we're taking this seriously and the information the community is providing on what use cases they are trying to solve is actually critical to coming up with the right solutions. The more we know about how our users leverage our projects and products, the better we can make them. Thanks in advance for your patience.
Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions?
At the moment, nothing that is public. This is larger than a bug at any rate.
Perhaps once there's a process for CentOS Stream community requests or interests that are larger in scope, someone could take the time to write up something that we can use to facilitate that discussion.
I agree with you that finding a proper solution to provide further/all subpackages is a larger endeavour and thus might take longer to solve.
However can we at least get all subpackages that are available for CentOS Linux now for CentOS Stream as well? I.e. populate the "Devel" repository for CentOS Stream with the same subpackages currently available in the CentOS Linux "Devel" repository.
This has been a blocker for me that stops me from even checking whether CentOS Stream might be an alternative for my use case since the announcement about CentOS Linux EOL last year.
It seems that the internal discussions about how to handle this in the future have even caused issues for the current partial solution: The Devel repository has not even been updated for CentOS Linux 8 (2011). Which means I'm still stuck at CentOS Linux 8 (2004) :(
And yes, these bugs have been reported.
These issues have caused me to now seriously look into alternative distributions despite having favored to switch to CentOS Stream for some time now. I'd really like to switch to CentOS Stream and continue to be a part of the CentOS Community, but it's getting harder to even convince myself that this is a good idea every day :(
Peter
josh _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jan 22, 2021 at 4:26 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions?
At the moment, nothing that is public. This is larger than a bug at any rate.
Perhaps once there's a process for CentOS Stream community requests or interests that are larger in scope, someone could take the time to write up something that we can use to facilitate that discussion.
I agree with you that finding a proper solution to provide further/all subpackages is a larger endeavour and thus might take longer to solve.
However can we at least get all subpackages that are available for CentOS Linux now for CentOS Stream as well? I.e. populate the "Devel" repository for CentOS Stream with the same subpackages currently available in the CentOS Linux "Devel" repository.
Possibly. I'm not sure it would show up in a "Devel" repo, but it's a smaller set to start with.
This has been a blocker for me that stops me from even checking whether CentOS Stream might be an alternative for my use case since the announcement about CentOS Linux EOL last year.
It seems that the internal discussions about how to handle this in the future have even caused issues for the current partial solution: The Devel repository has not even been updated for CentOS Linux 8 (2011). Which means I'm still stuck at CentOS Linux 8 (2004) :(
To be frank, that's probably my fault indirectly. Even if it isn't in whole, let's just proceed as if it was and see if we can find a more compelling solution for Stream.
These issues have caused me to now seriously look into alternative distributions despite having favored to switch to CentOS Stream for some time now. I'd really like to switch to CentOS Stream and continue to be a part of the CentOS Community, but it's getting harder to even convince myself that this is a good idea every day :(
I appreciate your patience. This isn't going to be quick, but we're definitely working on it.
josh
On Fri, Jan 22, 2021 at 12:46 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Jan 22, 2021 at 4:26 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions?
At the moment, nothing that is public. This is larger than a bug at any rate.
Perhaps once there's a process for CentOS Stream community requests or interests that are larger in scope, someone could take the time to write up something that we can use to facilitate that discussion.
I agree with you that finding a proper solution to provide further/all subpackages is a larger endeavour and thus might take longer to solve.
However can we at least get all subpackages that are available for CentOS Linux now for CentOS Stream as well? I.e. populate the "Devel" repository for CentOS Stream with the same subpackages currently available in the CentOS Linux "Devel" repository.
Possibly. I'm not sure it would show up in a "Devel" repo, but it's a smaller set to start with.
So I looked at this: http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
and noticed that some of those packages are already available in Stream in the PowerTools repo. Specifically:
http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/autog... http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/proto... http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/track...
quota-devel should be there, but isn't for some reason. I'll figure out why. libuv-devel should land there in the next few weeks as well.
The rest I'll look into.
josh
On 22/01/2021 19.33, Josh Boyer wrote:
On Fri, Jan 22, 2021 at 12:46 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Jan 22, 2021 at 4:26 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions?
At the moment, nothing that is public. This is larger than a bug at any rate.
Perhaps once there's a process for CentOS Stream community requests or interests that are larger in scope, someone could take the time to write up something that we can use to facilitate that discussion.
I agree with you that finding a proper solution to provide further/all subpackages is a larger endeavour and thus might take longer to solve.
However can we at least get all subpackages that are available for CentOS Linux now for CentOS Stream as well? I.e. populate the "Devel" repository for CentOS Stream with the same subpackages currently available in the CentOS Linux "Devel" repository.
Possibly. I'm not sure it would show up in a "Devel" repo, but it's a smaller set to start with.
So I looked at this: http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
and noticed that some of those packages are already available in Stream in the PowerTools repo. Specifically:
http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/autog... http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/proto... http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/track...
quota-devel should be there, but isn't for some reason. I'll figure out why. libuv-devel should land there in the next few weeks as well.
The rest I'll look into.
libuv-devel is one of the subpackages I'm particular interested in. Thanks for looking into it!
Peter
josh _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jan 22, 2021 at 2:49 PM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
On 22/01/2021 19.33, Josh Boyer wrote:
On Fri, Jan 22, 2021 at 12:46 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Jan 22, 2021 at 4:26 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions?
At the moment, nothing that is public. This is larger than a bug at any rate.
Perhaps once there's a process for CentOS Stream community requests or interests that are larger in scope, someone could take the time to write up something that we can use to facilitate that discussion.
I agree with you that finding a proper solution to provide further/all subpackages is a larger endeavour and thus might take longer to solve.
However can we at least get all subpackages that are available for CentOS Linux now for CentOS Stream as well? I.e. populate the "Devel" repository for CentOS Stream with the same subpackages currently available in the CentOS Linux "Devel" repository.
Possibly. I'm not sure it would show up in a "Devel" repo, but it's a smaller set to start with.
So I looked at this: http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
and noticed that some of those packages are already available in Stream in the PowerTools repo. Specifically:
http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/autog... http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/proto... http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/track...
quota-devel should be there, but isn't for some reason. I'll figure out why. libuv-devel should land there in the next few weeks as well.
The rest I'll look into.
libuv-devel is one of the subpackages I'm particular interested in. Thanks for looking into it!
Peter
The picking and choosing and pruning of "we'll publish some of the RPM's, but we'll either not publish or snip out of the Fedora .spec file devel packages we don't want to support" is seriously crazy-making. quota-devel is in the Devel channel. python3-talloc-devel cannot be found in RHEL or CentOS, even though it's written into the upstream Fedora libtalloc.spec file.I ran into this one backporting Sama 4.13 to CentOS 8.
On 1/21/21 4:02 PM, Josh Boyer wrote:
On Thu, Jan 21, 2021 at 9:57 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Putting all "unsupported" content in a separated -unsupported repo which would be disabled by default could be a suitable solution (similar to current Devel but automatically populated with unshipped content on each new build).
It's not a bad suggestion, but experience shows that naming or including "unsupported" in a repo or a package name doesn't mean much. If people can install it, they will. Also, we largely did that in RHEL 7. It is called the Optional repo and the content in there is unsupported. Let's just say it was not the deterrent that was originally envisioned and led to a number of problems.
This honestly is one of the issues that has been in the top five reasons that I will be transitioning all of the systems I manage, personal and business, to something else.
The package selection in RHEL is quite sparse, and is seemingly actively designed to make it difficult to impossible to build certain desirable enterprise packages, both at the server level and the workstation level. Missing buildrequires, missing -devel packages, missing PCI IDs in shipped drivers, and now the attitude that users need 'deterred' from installing unsupported packages.
Yes, I am fully aware of the cost to Red Hat of customer-installed unsupported packages, but I also have experienced the hoops one must jump and contort through to get certain needed packages (at least for us) built and running. Yes, I know customers will install things and then expect Red Hat to support the packages that they installed out of band, yes, I know all this. I know the reasoning; I just simply can't do things this way any more in my environment, and I was using CentOS anyway, so I had no expectation of support. Free RHEL will make it worse, not better, in this regard, since CentOS provided some of the packages that are needed to build other things, and free RHEL is the same binary distribution as non-free RHEL, meaning constraints and restrictions on packages that are allowed in a supported RHEL instance affect the free RHEL instances equally.
I have spent hundreds of hours rebuilding packages, from CentOS git when it was a case of an omitted subpackage (a seriously annoying thing, because then it blocks updates until I have another set rebuilt), from Fedora source RPM when possible for packages not in the CentOS git, from my own developed RPMs when RPMs are relatively easily supported but Fedora SRPMS aren't available, and from simple source tree using the upstream package's build regime (snaps, flatpaks, Anaconda3 (the python packaging system), PyPI, and other weirdnesses) because the upstream project seemingly has a vendetta against OS packages (Certbot, I'm looking at you!).
I've documented the process for a few of those, including posting, on the CentOS forums, my success building one such difficult package several months ago (the package was KiCAD 5.x). Most of the issues were with workstations, but when I began building the Canvas LMS for a server here I entered into a whole new world of packaging pain that I didn't know existed, this THING called Node.js. Python and Perl subpackages were and are hard enough (I packaged PostgreSQL years ago, and the Python and Perl subpackages were the most 'fun'); why does every project think they just MUST reinvent the packaging wheel?
Packaging and repackaging have been so central to my needs that one of the first things I started reading about when I started looking at the alternatives was how to build packages. It sounded sad enough thinking it; re-reading it after typing it - it really sounds sad now that my choice of distribution going forward is somewhat predicated upon how easy it would be to patch that distribution's package breakage.
Hi Lamar,
On 1/21/21 4:02 PM, Josh Boyer wrote:
On Thu, Jan 21, 2021 at 9:57 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Putting all "unsupported" content in a separated -unsupported repo which would be disabled by default could be a suitable solution (similar to current Devel but automatically populated with unshipped content on each new build).
It's not a bad suggestion, but experience shows that naming or including "unsupported" in a repo or a package name doesn't mean much. If people can install it, they will. Also, we largely did that in RHEL 7. It is called the Optional repo and the content in there is unsupported. Let's just say it was not the deterrent that was originally envisioned and led to a number of problems.
This honestly is one of the issues that has been in the top five reasons that I will be transitioning all of the systems I manage, personal and business, to something else.
The package selection in RHEL is quite sparse, and is seemingly actively designed to make it difficult to impossible to build certain desirable enterprise packages, both at the server level and the workstation level. Missing buildrequires, missing -devel packages, missing PCI IDs in shipped drivers, and now the attitude that users need 'deterred' from installing unsupported packages.
Yes, I am fully aware of the cost to Red Hat of customer-installed unsupported packages, but I also have experienced the hoops one must jump and contort through to get certain needed packages (at least for us) built and running. Yes, I know customers will install things and then expect Red Hat to support the packages that they installed out of band, yes, I know all this. I know the reasoning; I just simply can't do things this way any more in my environment, and I was using CentOS anyway, so I had no expectation of support. Free RHEL will make it worse, not better, in this regard, since CentOS provided some of the packages that are needed to build other things, and free RHEL is the same binary distribution as non-free RHEL, meaning constraints and restrictions on packages that are allowed in a supported RHEL instance affect the free RHEL instances equally.
I have spent hundreds of hours rebuilding packages, from CentOS git when it was a case of an omitted subpackage (a seriously annoying thing, because then it blocks updates until I have another set rebuilt), from Fedora source RPM when possible for packages not in the CentOS git, from my own developed RPMs when RPMs are relatively easily supported but Fedora SRPMS aren't available, and from simple source tree using the upstream package's build regime (snaps, flatpaks, Anaconda3 (the python packaging system), PyPI, and other weirdnesses) because the upstream project seemingly has a vendetta against OS packages (Certbot, I'm looking at you!).
I've documented the process for a few of those, including posting, on the CentOS forums, my success building one such difficult package several months ago (the package was KiCAD 5.x). Most of the issues were with workstations, but when I began building the Canvas LMS for a server here I entered into a whole new world of packaging pain that I didn't know existed, this THING called Node.js. Python and Perl subpackages were and are hard enough (I packaged PostgreSQL years ago, and the Python and Perl subpackages were the most 'fun'); why does every project think they just MUST reinvent the packaging wheel?
Packaging and repackaging have been so central to my needs that one of the first things I started reading about when I started looking at the alternatives was how to build packages. It sounded sad enough thinking it; re-reading it after typing it - it really sounds sad now that my choice of distribution going forward is somewhat predicated upon how easy it would be to patch that distribution's package breakage.
Thanks for speaking this out so clearly and detailed. I can confirm every sentence from my experience and I'm glad I'm not alone :)
When you said Node.js I had to smile. My only fear is to think about what's coming next and over next.
In the end this is a general problem, not related to Linux alone. But there is also a lot of pain with Linux alone where other UNIX (like) OSes don't behave so bad. Just think back to the ipchains days, and how things have changed over the years. And the net-tools struggle ending up in completely new network tools which make Linux unique in the *X world. Then the lack of in place upgrades for most distributions. The sound system diversity. Not to forget new init systems which turn the whole system and your knowledge about it upside down. Maybe I should also mention filesystems and the underlying infrastructure, where it would be nice to have one or two very good solutions instead of a zoo. The list goes on...
Sometimes I feel I really spent too much of my working time just for catching up with the constant changes and I'm wondering why it is like that. That's a question for every Linux contributor but also directly to the big contributors like RedHat.
Simon
On Fri, 22 Jan 2021 at 09:51, Simon Matter simon.matter@invoca.ch wrote:
Hi Lamar,
Sometimes I feel I really spent too much of my working time just for catching up with the constant changes and I'm wondering why it is like that. That's a question for every Linux contributor but also directly to the big contributors like RedHat.
I think many of us in the 'modern industries' have to spend a good portion of our lives relearning everything. We either do it a bit constantly or find ourselves outdated and struggling to make giant leaps because our skills are no longer 'needed'. I have seen this in everything from automobile shops, textile plants, chemical factories, government bureaucracies and even farming. The only way things stay the same are when they get artificially 'protected' by a large enough society forces their government that they are willing to keep say XYZ cheese making exactly the way it was done in 1420. [Usually whatever it is has to tie deeply into national pride and have been going on for hundreds of years to get that mark so at this point steam powered computers is probably the only thing which would get this point (sorry Cobol)]
Otherwise we find that we are relearning things all the time or being replaced by someone younger who is 'up on the new things'. Then we have to fight with others in the 'heritage' pile where there is an oversupply of people and undersupply of jobs. Then the only way to shine there is being a consultant who can sell themselves better than the others and command that price you want. However usually that also means being up on the new things enough because you are going to be transitioning whatever 'heritage' to something new enough to find less expensive people later.
Simon
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jan 22, 2021 at 9:22 AM Lamar Owen lowen@pari.edu wrote:
On 1/21/21 4:02 PM, Josh Boyer wrote:
On Thu, Jan 21, 2021 at 9:57 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Putting all "unsupported" content in a separated -unsupported repo which would be disabled by default could be a suitable solution (similar to current Devel but automatically populated with unshipped content on each new build).
It's not a bad suggestion, but experience shows that naming or including "unsupported" in a repo or a package name doesn't mean much. If people can install it, they will. Also, we largely did that in RHEL 7. It is called the Optional repo and the content in there is unsupported. Let's just say it was not the deterrent that was originally envisioned and led to a number of problems.
This honestly is one of the issues that has been in the top five reasons that I will be transitioning all of the systems I manage, personal and business, to something else.
The package selection in RHEL is quite sparse, and is seemingly actively designed to make it difficult to impossible to build certain desirable enterprise packages, both at the server level and the workstation level. Missing buildrequires, missing -devel packages, missing PCI IDs in shipped drivers, and now the attitude that users need 'deterred' from installing unsupported packages.
To be clear, customers need to be deterred from inadvertently walking themselves into unsupported situations and then being surprised about it later. That's the part that wasn't successful about Optional. Availability and installation of those packages is perfectly fine as long as people are aware of the implications. Every customer and user has different risk tolerances and development models. So it's not "don't install these packages", it's "understand what it means to rely on these packages".
Yes, I am fully aware of the cost to Red Hat of customer-installed unsupported packages, but I also have experienced the hoops one must jump and contort through to get certain needed packages (at least for us) built and running. Yes, I know customers will install things and then expect Red Hat to support the packages that they installed out of band, yes, I know all this. I know the reasoning; I just simply can't do things this way any more in my environment, and I was using CentOS anyway, so I had no expectation of support. Free RHEL will make it worse, not better, in this regard, since CentOS provided some of the packages that are needed to build other things, and free RHEL is the same binary distribution as non-free RHEL, meaning constraints and restrictions on packages that are allowed in a supported RHEL instance affect the free RHEL instances equally.
I have spent hundreds of hours rebuilding packages, from CentOS git when it was a case of an omitted subpackage (a seriously annoying thing, because then it blocks updates until I have another set rebuilt), from Fedora source RPM when possible for packages not in the CentOS git, from my own developed RPMs when RPMs are relatively easily supported but Fedora SRPMS aren't available, and from simple source tree using the upstream package's build regime (snaps, flatpaks, Anaconda3 (the python packaging system), PyPI, and other weirdnesses) because the upstream project seemingly has a vendetta against OS packages (Certbot, I'm looking at you!).
The missing subpackages are indeed painful and we're aware of it.
I've documented the process for a few of those, including posting, on the CentOS forums, my success building one such difficult package several months ago (the package was KiCAD 5.x). Most of the issues were with workstations, but when I began building the Canvas LMS for a server here I entered into a whole new world of packaging pain that I didn't know existed, this THING called Node.js. Python and Perl subpackages were and are hard enough (I packaged PostgreSQL years ago, and the Python and Perl subpackages were the most 'fun'); why does every project think they just MUST reinvent the packaging wheel?
That's a good question and it's not an easy one to answer. Increasingly upstreams are using distribution models that eschew the traditional distribution model of yesterday. Matthew Miller, the Fedora Project Leader, gave a great talk related to this a while ago. He pointed out in the early days, getting your package into a Linux distribution was the primary way to make it popular and meet your users. Over time that's become less and less of the case, with competing package formats, pace of distributions, and version choice (or proliferation) all leading to developers wanting more control over the software stack. CPAN, the nodejs ecosystem, pip, rust crates, etc are all examples of upstream approaches to accommodate this.
When you extend those factors to a long lifecycle enterprise focused environment, things become even more challenging. Increasingly we're trying to focus the operating system on meeting the fundamental needs while providing choice in some of these areas. However we can't provide every possible version, and often developers don't want us to anyway. It's been a really hard problem to think about and try to address and we're always trying to evolve there.
josh
-
Alfredo Moralejo Alonso -
Fabian Arrotin -
Josh Boyer -
Lamar Owen -
Nico Kadel-Garcia -
Peter Georg -
Simon Matter -
Stephen John Smoogen -
Xavier Bachelot