[gentoo-dev] adding sec-keys/openpgp-keys-gentoo-release to @system

[gentoo-dev] adding sec-keys/openpgp-keys-gentoo-release to @system

[Andreas K. Huettel]

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

Dear all, 

I'd like to add 

  sec-keys/openpgp-keys-gentoo-release

to @system - any objections?

The package contains a single file (~20k) with the public keys used for stage,
manifest, and binpackage signing.

This is more of a formal request since portage already depends on it anyway, and
the package is present in every stage3. However, it in my opinion makes sense
to explicitly state that it needs to be present.

Cheers,
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding sec-keys/openpgp-keys-gentoo-release to @system

[Rich Freeman]

On Sat, Aug 12, 2023 at 10:34 AM Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>
> I'd like to add
>
>   sec-keys/openpgp-keys-gentoo-release
>
> to @system - any objections?
>
> This is more of a formal request since portage already depends on it anyway, and
> the package is present in every stage3. However, it in my opinion makes sense
> to explicitly state that it needs to be present.

This seems like the opposite of making the dependency explicit.  It is
already explicit, because everything that actually needs it depends on
it.  If you stick it in @system then the packages that need it will
remove the dependency, and it will become less clear what actually
uses it.

IMO @system is a design flaw.  The most obvious impact of it is a
large number of packages that cannot be built in parallel, because
portage can't know what packages depend on packages in @system,
because we don't specify these dependencies.

Obviously getting rid of @system would take a fair bit of effort to
capture all the dependencies, and have the stage3 builds pull from a
meta-package or something similar.  However, at the very least it
would be best to avoid adding more to it.

@system is also one of the reasons why some configuration changes can
be accomplished via USE flags and virtual packages, and other
configuration changes must be accomplished via profiles.  For example,
supporting multiple sets of signing keys would be simpler with these
just being pulled in by virtual packages and USE flags, and harder if
these all required profiles or something like Funtoo mix-ins.

Obviously this package is one of the less impactful ones to add to
@system, but I figured I'd at least toss that out as food for
thought...

-- 
Rich