[CentOS] Fedora bugs and EOL [was Re: CentOS users: please try and provide feedback on Fedora] Boltron

Wed Aug 2 13:17:36 UTC 2017
Mark Haney <mark.haney at neonova.net>

On 08/02/2017 08:27 AM, hw wrote:
> Jonathan Billings wrote:
>> I’m confused, are you talking about Gentoo, Fedora, CentOS or RHEL?
> I´m talking about Centos here and am referring to experiences with other
> distributions at the same time.
> Like Gentoo is great but horrible to keep up to date, and in doing so,
> you are expected to become a package manager yourself.  Things introduced
> into Fedora might make their way into RHEL/Centos, and introducing
> multiversion-packages into Fedora might lead to introducing them into 
> Centos.
I ran very early Gentoo versions (2005 to 2010) on my work laptop (a 
Compaq of all things) without any trouble.  I had very few issues with 
failed updates, since they are compiled on my system with my switches. 
The biggest PITA was to get the right switches added to get what you 
really wanted on the system.  I tinkered with KDE options for a couple 
of weeks (and the long compile times), but there weren't any issues 

> Once they have been introduced, we need to become package managers 
> much as
> with Gentoo in order to figure out which versions of which packages work
> together.  And that´s just the tip of the iceberg.
I don't this is as making us (the end user) package maintainers as much 
as package /controllers/.  I would fail to see much need to maintain 
multiple package versions on a system except for debugging/testing.  
However, as a former developer, I think this would make debugging much 
quicker and that's not a bad thing.  On the DevOps/Systems Engineering 
side (my focus over the last decade), this could possibly be a PITA if 
devs were allowed to run multiple package versions in production 
systems.  That's still not package maintainers, but a measure of control 
over them.
> What will happen when you report a bug in version N of package foo, 
> perhaps
> a bug that was fixed in version N+2?  Are they going to fix it, or 
> will they
> wait until the distribution goes EOL and/or tell you to use version 
> N+2 ---
> which you can´t use because feature X is missing in that version, 
> which is
> why you are using version N.
They do that sort of thing all the time, it's called backporting. And 
lots of patches are backported.  Most of that is a function of how /far 
back/ to be backported, etc.  If they don't backport, you have a couple 
of options, backport it yourself, or find a comparable package with the 
features you need.
> Being able to use that very version N is the point of 
> multiversion-packages.
> Not maintaining all provided versions of such packages accordingly would
> defeat the whole purpose.
That's insane.  Who in their right mind want to continue to maintain 
version 1.0 of a package when the current one is version 10.0 and there 
are 30 stable versions in between?  No one.  What are the odds the 
version 1.0 package would still be used in that situation? (even given 
short release times)
> Perhaps issues like this haven´t been considered yet, that´s why I´m
> providing feedback as was asked for, after finding out that the form they
> have prepared to get feedback doesn´t allow to do so.  I´m aware that 
> this
> is feedback they don´t want to hear and will either ignore or 
> encounter with
> unkindness.
> Perhaps I´m entirely wrong and misunderstanding what they´re trying to 
> do,
> yet so far nobody has said so.

I don't think you're wrong, and I don't think you're misunderstanding 
either.  It's kind of a bit of both, however contradictory that sounds.  
To me, Boltron seems to be a start on an idea whose time has come.  
Maybe it's too early for it, but I'm really looking to put it through 
it's paces to see how well it does work in real life situations.

Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.haney at neonova.net