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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
