Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14

[Mitchell Dorrell <mwd@psc.edu>]

[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

How will the upgrade path look, from e.g. 3.16 to 3.17? What will the
typical Gentoo user experience be? What will the experience be for a Python
developer with a local overlay containing custom Python packages?

I didn't like this idea at first, but I'm warming up to it.

On Sat, Oct 12, 2024, 06:05 Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 2024-10-12 at 11:59 +0200, Ulrich Mueller wrote:
> > > > > > > On Sat, 12 Oct 2024, Michał Górny wrote:
> >
> > > However, I think the cleanest way forward would be to stop slotting
> > > CPython like this, and instead have a separate package for each
> version,
> > > just like the vast majority of distributions do, i.e.:
> >
> > >   dev-lang/python3_N
> >
> > That other distributions do it that way is not an argument because most
> > other distributions don't have slots.
> >
> > > This naturally means that only the specific version requested (e.g. via
> > > targets) would be installed, and no cross-slot autoupgrades would
> > > happen.  Ideally, I'd like to start doing that with Python 3.14 whose
> > > first alpha is expected next week.  Depending on how they handle
> > > freethreading, we'd end up having the first or both of:
> >
> > >   dev-lang/python3_14
> > >   dev-lang/python3_14t
> >
> > IMHO this would abuse the package name for information that absolutely
> > doesn't belong there. It belongs in PV or SLOT.
> >
> > To me it seems that you try to work around a problem (greedy upgrade
> > behaviour) that should really be solved in the package manager.
>
> In my opinion, it's the other way around.  We have slots, that are a fit
> solution for packages that are roughly compatible between every major
> release, and we keep abusing them for every single thing we can bend
> enough to make it fit.
>
> Greedy upgrade behavior makes sense when you have packages where :=
> and :* operators are applicable.  It doesn't make sense when every
> single dependency is expected to specify an explicit slot.  In fact,
> when you are never supposed to depend on the package without specifying
> a slot, why would you think slots are the right solution?
>
> In fact, the "freethreading" variation already implies that there could
> be more than one "slot" per package version.
>
> It's as meaningless as having sqlite3 packaged as sqlite:3, or gtk that
> is now randomly split between gtk+:2, gtk+:3 and gtk:4.
>
> --
> Best regards,
> Michał Górny
>
>

[-- Attachment #2: Type: text/html, Size: 3101 bytes --]