[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: EGO_SUM
From:       Arsen =?utf-8?Q?Arsenovi=C4=87?= <arsen () gentoo ! org>
Date:       2023-05-31 9:06:55
Message-ID: 86a5xk982o.fsf () gentoo ! org
[Download RAW message or body]


Andrew Ammerlaan <andrewammerlaan@gentoo.org> writes:

> On 30/05/2023 18:35, Arthur Zamarin wrote:
>> My solution is as such:
>> 1. Undeprecate EGO_SUM in eclass
>> 2. Forbid it's usage in ::gentoo (done by pkgcheck, error level, will
>> fail CI and as such we can see the misuse). Overlays are allowed.
>> 3. Maintainer starts talks with upstreams to add release workflow to
>> create vendored source tarball, in hopes of it succeeding. "Start early,
>> to future profit". I see this flow similar to the "always try to
>> upstream patches".
>> 4. Until upstream adds it, in ::gentoo use vendor tarballs.
>> I also think many devs agree with this solution, but I can't talk for
>> them, so I'll be happy agreeing devs can at least reply shortly their
>> agreement or disagreement.
>
> I fully agree with Arthur

+1

> With regards to proxy-maintained packages: The proxy can generate and upload
> the vendor tarball for the proxied, this is not that much extra work.

This expands the required trust in proxy maintainers, in a way which is
unusually easy to double check.

We can automate generating vendor tarballs (or more).  If implemented
such that tarballs are reproducible, it should be easy to verify by
running the same procedure from a different host and verifying.

There would still be a slight cost to an initial 'whitelist package'
step or such, but IMO, that's not a very large cost.  (and, also,
possibly some other mechanism could be implemented)

> Best regards,
> Andrew


-- 
Arsen Arsenović

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]