Mark Haney wrote: > 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. It works better when you have the time to update every day or at least every week. Still you´re in a circle because you know that an update may not work and have to expect them to be time consuming, so, unless you have huge amounts of time at your disposal, you need to defer the updates to when you have time, which makes the problem worse. They even go so far to make changes after which it suddenly becomes impossible to update. The problem might still be solvable, but it requires too much effort. >> 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. Ok, since they run within containers, they can be tested without affecting the versions that are currently in use, so that can be a nice advantage. >> 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. I wonder where the resources to do that for multiple versions of packages are suddenly coming from. >> 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) Why would you package version 1.0 when you don´t want to maintain it? >> 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. Well, I think I understand the idea a bit better now, and I guess it´s something some people are going to like a lot.