Bug 885827 – PROPERTIES token for binary (non-source) packages

• Product: Gentoo Hosted Projects
• Status: CONFIRMED ---

[Description Sam James 2022-12-14 02:57:43 UTC]

I propose a new PROPERTIES token for "binary" to indicate a package contains some binary elements and is not built from source.

Users ask quite frequently if there's a way to mask all "-bin" packages.

But not all packages solely available as a binary have a -bin suffix in their package name. For example, www-client/microsoft-edge does not have a -bin suffix. Typically, a package will only have a -bin suffix if there's a prospect of one day it being built from source.

Licencing is not an accurate proxy for this either, as for example dev-lang/ghc is FOSS, but a binary is needed to install it, which requires trusting the provider of that binary (which may be a 3rd party like upstream, or a Gentoo developer, or ...).

Such a token would allow users to set ACCEPT_PROPERTIES="-binary" in make.conf if they are uncomfortable with blobs in general.

In addition to licencing & purity concerns, the PROPERTIES token will be useful for identifying packages which need special care in porting to new architectures or platforms.

[Comment 1 Sam James 2022-12-14 03:03:35 UTC]

Two more remarks:
* I think this is essentially following the same path as with live ebuilds where we realised 9999* is not a very good classifier and invented PROPERTIES="live" eventually.

* Ionen noted the link w/ QA_PREBUILT which is a fair point. Aim for PROPERTIES="binary" would be to include if the build process requires a binary blob, even if it's not then installed (ghc, sbcl, rust if not USE=system-bootstrap).

Given the primary motivation for this is allowing people to check for purity of packages, my expectation is that we'd use this for tainting if a package contains any non-optional blobs, but that's more of a policy discussion I suppose rather than something for the PMS side.

[Comment 2 Ulrich Müller 2022-12-14 10:28:31 UTC]

How would this affect the operation of the package manager?

[Comment 3 Ulrich Müller 2022-12-14 10:47:48 UTC]

See also previous discussion:
https://archives.gentoo.org/gentoo-dev/message/25db0027e000ab6a85f8c2535a42f502
(which adds an additional "upstream" vs "gentoo" qualification, not sure if we would need that?)

Alternative approach, antarus's package tags:
https://wiki.gentoo.org/wiki/User:Antarus/Package_Tags

[Comment 4 Sam James 2023-03-08 21:45:09 UTC]

(In reply to Ulrich Müller from comment #2)
> How would this affect the operation of the package manager?

It'd let people exclude them as desired, or avoid making binpkgs of them as it's a waste of time (like bindist).