I'll start by saying this wasn't the smoothest Python upgrade relative to previous ones, I think many of us can agree on that.
In my case, I had completely forgotten about it until 1 June when portage exploded with complaints. The common culprit was obviously Python from the change flags. Then I remembered reading the news a few weeks back, and went down the 3-step route. Maintaining 3.11 and letting other non-related upgrades complete with:
*/* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11
was the first step which was absolutely fine and did not break anything.
Then I dealt with Python as per the news item. Unfortunately, some
packages weren't migrated, for various reasons, and I ha
d two options:1) keep my newly introduced flags above to maintain compatibility and migrate at a later point when things are more polished, or
2) remove those packages, if I don't need to use them day to day, and install them at a later point when they're ready.
I *personally* chose (2) as neither were mission critical for me, but this is a choice I made consciously. (1) would have worked just as well.
Which nicely takes me to this: On 05/06/2024 14:11, Joost Roeleveld wrote:
Here is the problem. Not all "system-critical" packages were stabilised before this change was pushed.
Which packages do you consider to have been 'system critical' in this instance and why do you classify them as such? Without establishing a definition, anything can be 'ssytem-critical' from a subjective point of view.
I tend to agree with Rich's definition: > anything system-critical (as in you won't be able to boot or use > the package manager/etc) I'd hate to take 'centrist' position but:1) Could this have been a smoother sail? Yes, I think so, given that on 1 June about half of the _tracked_ bug items in the overarching compatibility tracking bug item were not ready. It probably would have merited for the switchover to be deferred. But also:
2) Was anything really 'broken'? Most certainly no, going by the above definition and the fact that the news item provided for a very clear pathway to maintain compatibility that was essentially a two-line solution.
In fact, none of what happened was completely outside of my expectations. With Gentoo being self-described as a 'meta-distribution' due to 'no two installs being truly identical', conflicts arising from USE flag changes are relatively common, at least in my experience. And this is part and parcel of having the flexibility that Gentoo offers us. I've learnt to deal with it and more often than not the solution is reasonably straightforward. I most cert ainly do not expect of Gentoo to behave the same as 'apt dist-upgrade' on Debian or equivalent in binary distros.
If the latter is your expectation, have you considered whether Gentoo would be the most appropriate choice for maintaining those 21 or so hosts? This isn't to say it's a bad choice...
In my (personal) experience of 15+ years of using Gentoo, I've never had a truly irrecoverable situation, despite having quirks. In fact, I was expecting a much more difficult changeover to the 23 profiles, and even that far exceeded my expectations.
Perhaps it does boil down to having different expectations. And if that's the case - is Gentoo the most appropriate for you personally or your use case?
- Victor
signature.asc
Description: OpenPGP digital signature
