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 usually. > 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 www.neonova.net