On Sat, 2024-10-12 at 15:00 +0200, Luca Barbato wrote:
> On 12/10/24 11:13, Michał Górny wrote:
> > On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
> > > On 12/10/24 10:12, Michał Górny wrote:
> > > > Comments?
> > > >
> > > I'm afraid it would lead to way too many packages and I'm not sure the
> > > overall experience would be an improvement.
> >
> > 5 are too many?
>
> potentially it is python_{version}_{variants} so at least 10*2 assuming
> we keep around 3.{N..N+5} and we have two worthy variants.
>
> Plus the chore of treecleaning older packages. Not sure if it is worth it.That sounds like an advantage, actually. Currently, we keep older versions for a long time, then they suddenly disappear. All the things considered, perhaps we ought to verbosely last rite them. > > In fact, even today "emerge dev-lang/python" is probably a bad solution, > > as it will lead to a beta/rc version on an ~arch system most > > of the time. > > > > > An alternative for freethreading support wouldn't be to install both > > > from the same package python-3.14 and have the two PYTHON_TARGETS ? > > > > I don't understand. > > emerge =python-3.14 would install both a non-freethreading and a > freethreading version and it would satisfy 3_14 and 3_14t at the same. > But that's not how PMs work? It would install only the "newer" version, which would probably mean freethreading, which is not what people usually want. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
