On Sat, Oct 12, 2024, 06:23 Michał Górny wrote:
> On Sat, 2024-10-12 at 12:13 +0200, Ulrich Mueller wrote:
> > > > > > > On Sat, 12 Oct 2024, Michał Górny wrote:
> >
> > > > IMHO this would abuse the package name for information that
> absolutely
> > > > doesn't belong there. It belongs in PV or
On Sat, 2024-10-12 at 07:23 -0400, Mitchell Dorrell wrote:
> On Sat, Oct 12, 2024, 06:23 Michał Górny wrote:
>
> > On Sat, 2024-10-12 at 12:13 +0200, Ulrich Mueller wrote:
> > > > > > > > On Sat, 12 Oct 2024, Michał Górny wrote:
> > >
> > > > > IMHO this would abuse the package name for informat
On Sat, 12 Oct 2024 10:12:56 +0200
Michał Górny wrote:
> Hello,
>
> Historically, all versions of CPython were slotted in a single
> package, i.e.:
>
> dev-lang/python:3.N
>
> This approach has been causing a major annoyance for users -- due to
> Portage "greedy" upgrade behavior, any time a
On 2024-10-12 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?
Absolutely n
On Samstag, 12. Oktober 2024 15:52:45 MESZ orbea wrote:
> Its already a serious chore keeping the python ebuilds in sync
> with ::gentoo and if you start to double the versions that will only be
> more ridiculous.
Life choices.
signature.asc
Description: This is a digitally signed message part.
On Sat, Oct 12, 2024, 14:03 Michał Górny wrote:
> On Sat, 2024-10-12 at 10:12 +0200, Michał Górny wrote:
> > 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
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
Signed-off-by: Michał Górny
---
dev-lang/python/Manifest | 2 +-
dev-lang/python/python-3.13.0.ebuild | 8 +---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/dev-lang/python/Manifest b/dev-lang/python/Manifest
index daddb0dad1f4..7663f0072d2a 100644
--- a/dev-lang
Signed-off-by: Michał Górny
---
eclass/verify-sig.eclass | 54
1 file changed, 49 insertions(+), 5 deletions(-)
diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
index 9886e3352db7..f97c4a276865 100644
--- a/eclass/verify-sig.eclass
+++ b/e
New package installing trusted_root.json for dev-python/sigstore,
to verify signatures. Includes a test phase to verify if our root
is up-to-date.
Signed-off-by: Michał Górny
---
sec-keys/sigstore-trusted-root/Manifest | 2 +
sec-keys/sigstore-trusted-root/metadata.xml | 8 +++
.../si
Hi,
dev-python/sigstore is yet another NIH signature verification tool.
Python is planning to use it exclusively starting with Python 3.14.
It uses some fancy PKI-like infrastructure backend by OAuth against
some popular providers (read: now Google and Microsoft will hold keys
used to sign Python
Signed-off-by: Michał Górny
---
eclass/verify-sig.eclass | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
index b74ed78290aa..d601c7838a00 100644
--- a/eclass/verify-sig.eclass
+++ b/eclass/verify-sig.eclass
@@ -13
Signed-off-by: Michał Górny
---
eclass/verify-sig.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
index d601c7838a00..9886e3352db7 100644
--- a/eclass/verify-sig.eclass
+++ b/eclass/verify-sig.eclass
@@ -173,6 +173,9 @@ verif
On Sat, 2024-10-12 at 17:30 +0500, Anna (cybertailor) Vyalkova wrote:
> On 2024-10-12 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
Michał Górny writes:
> 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?
>
>> With your
Mitchell Dorrell writes:
> 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?
It should be transparent because PYTHON_COMPAT wi
On 12/10/24 15:03, Michał Górny wrote:
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, whic
On 12/10/2024 10:12, Michał Górny wrote:
This approach has been causing a major annoyance for users -- due to
Portage "greedy" upgrade behavior, any time a new Python version was
keyworded, Portage insisted on installing it, even though user's
selected targets did not request the specific version
On Sat, 2024-10-12 at 10:12 +0200, Michał Górny wrote:
> 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
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
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:
Hello,
Historically, all versions of CPython were slotted in a single package,
i.e.:
dev-lang/python:3.N
This approach has been causing a major annoyance for users -- due to
Portage "greedy" upgrade behavior, any time a new Python version was
keyworded, Portage insisted on installing it, even
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.
With your proposed solution, if an user wants to have any version of
python what should ask to emerge?
An alternative for free
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?
> With your proposed solution, if an user want
On Sat, Oct 12, 2024 at 10:12:56AM +0200, Michał Górny wrote:
> Historically, all versions of CPython were slotted in a single package,
> i.e.:
>
> dev-lang/python:3.N
>
> This approach has been causing a major annoyance for users -- due to
> Portage "greedy" upgrade behavior, any time a new Py
> 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
On Sat, 2024-10-12 at 11:49 +0200, Eray Aslan wrote:
> On Sat, Oct 12, 2024 at 10:12:56AM +0200, Michał Górny wrote:
>
> > As a side notice, the existing versions would probably remain as-is
> > until removal, since there's really no gain in splitting them, given
> > we'd have to retain compatibil
> On Sat, 12 Oct 2024, Ulrich Mueller wrote:
> 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 packa
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 di
On Sat, 2024-10-12 at 12:03 +0200, Ulrich Mueller wrote:
> > > > > > On Sat, 12 Oct 2024, Ulrich Mueller wrote:
>
> > 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 probl
> On Sat, 12 Oct 2024, Michał Górny wrote:
>> 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
On Sat, 2024-10-12 at 12:13 +0200, Ulrich Mueller wrote:
> > > > > > On Sat, 12 Oct 2024, Michał Górny wrote:
>
> > > 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
32 matches
Mail list logo
