On 6/5/24 1:12 PM, byte.size...@simplelogin.com wrote: > 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:
I would take a somewhat less than centrist position, but:
Let's take the number of ebuilds in the gentoo repository that declare
they depend on some version of python:
# ebuild files declaring the use of python eclasses
git grep --name-only PYTHON_COMPAT '*.ebuild'|
# filtered by category/pkg and deduplicated
awk -F/ '{print $1"/"$2}'| sort -u |
# ... and count them
wc -l
For a total of 2954 packages that needed to somehow be ported.
Now here's the list, as of right this second, of packages that still
need to be ported to support 3.12. This is the same information used to
create the tracker bug:
curl -Ls https://qa-reports.gentoo.org/output/gpyutils/311-to-312.txt |
wc -l
278 packages.
The list includes packages that optionally use python, packages that
only use python when building with FEATURES=test, vim which I can
actually confirm I have a patch queued to sync the live ebuild, because
its presence here is a false positive caused by that, etc -- but most of
them probably need python at runtime on people's systems, which is fair
enough.
That's about 1/10 of packages in gentoo. A bit less, really. Some
notable standouts are:
- libreoffice-bin, depends solely on the cpython interpreter
- kicad
- mumble
- firefox ESR, but not the latest version, depends solely on the
interpreter
freecad works with py3.12 but you have to use qt6. This was updated on
June 3.
A lot of these packages are science software, especially.
Regarding the tracker bug itself, there's a total of 949 bugs linked to
it. 293 of them are open today. Including all open and closed ones
together, it's only a third of the total number of python packages in
gentoo.
The tracker bug existed basically to track the laggard packages.
> 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.
+1
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
