From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: The meaning of attributes in repositories.xml?
Date: Fri, 28 Mar 2025 08:23:42 -0000 (UTC) [thread overview]
Message-ID: <pan$215dc$6197ae64$428feea5$b0e11aa6@cox.net> (raw)
In-Reply-To: e1b1782524de579077d89b862a5302d60656e20f.camel@gentoo.org
Michał Górny posted on Fri, 28 Mar 2025 05:27:40 +0100 as excerpted:
> Hello,
>
> I've looked at our repositories.xml and the quality/status attributes
> don't seem to be used very meaningfully.
>
> That is, by quality:
>
> core: gentoo [official]
> stable: opentransactions (?) [official (?!)]
> testing: hyprland-overlay, moexiami [both unofficial]
> experimental: everything else graveyard: unused
>
> By status:
>
> official: ago, alexxy, anarchy, andrey_utkin, cj-overlay, dilfridge,
> emacs, EmilienMottet, fordfrog, gentoo, gnome, gnustep, graaff, guru,
> haskell, java, jmbsvicetto, kde, libressl, maekke, masterlay, mschiff,
> multilib-portage, musl, mysql, opentransactions, pentoo, pinkbyte,
> qemu-init, qt, R_Overlay, rich0, riscv, rnp, ruby, science, sping,
> swegener, tex-overlay, toolchain, ukui, ulm, vGist, voyageur, x11
>
> unofficial: everything else
>
>
> Which brings the significant question: are these attributes in any way
> meaningful? Is there a point in keeping them at all? Should we set
> some ground rules and make them used consistently?
>
> Of them all, only "core" makes sense right now. "stable" and "testing"
> are used only by random user overlays, with no apparent features.
> Similarly, "official" is used by a mix of developer and ex-developer
> repositories, developer and user project repositories, and a bunch of
> user repositories with no clearly distinct features.
So what you didn't mention but I assume knew, thus making your question
more one of: "This seems to have changed, do we get stricter again or lose
the attributes which don't seem to mean anything any more"...
My (user) understanding from "back in the day" when overlays were fairly
new and I first merged and configured layman (reading its config docs
where IIRC this came from to do so), keeping in mind that back then
overlays were a new concept and a major point from the detractors was fear
that actually providing official overlays management and documentation
would somehow implicate Gentoo if a user took advantage to distribute
overt malware:
Status:
* "Official" status meant managed by an official Gentoo project or
developer (who had gone thru the usual vetting process), thereby implying
the same security-trust level as the main Gentoo tree. That is,
regardless of quality (experimental, testing, etc), the contents should be
relatively trustworthy at minimum not to include deliberate ebuild/eclass
level malware.
The implication of "official" was that any deliberate or "they went
through the vetting process and should have known better" security
violation (as opposed to quality/QA violation) in any "official" overlay
would be treated as if it had occurred in the main overlay, and would not
only trigger ejection of the dev in question but a reexamination of what
could be done to improve vetting to avoid it happening again in the
future, as well as possible prosecution as appropriate.
* "Unofficial" status had rather less security-trust and was intended for
"ordinary users". Unvetted, "caveat emptor", "here be dragons" and "if it
breaks you get to keep the pieces". Security violations would of course
result in removal of the overlay from the list... after the fact.
The implication was "If it's from an unofficial overlay, be sure you
either trust the author with effective root on your system or explicitly
examine the code before running it, because effective root on your system
is what you're giving them."
...
I thus find it ... "unsettling"... to read that various user overlays have
apparently been marked "official" with no regard to that original policy.
While the original distinction may have arguably had alarmist motivations,
I definitely still find it useful, within a somewhat more limited context,
and consider "official" status among other factors when I consider adding
an overlay.
Guru specifically, given its purpose and that I personally have it active
(but ATM unused), I wonder about having official status. I only "sort of"
use one ebuild from there, net-nntp/pan -- "sort of" because I used it as
a basis for my personal overlay's pan-9999 live-git ebuild, when upstream
switched autotools -> cmake. (FWIW I've been "going to" contact and
coordinate with the primary author and perhaps add the -9999 version to
guru as well once we do, but that's yet to happen...) Obviously I did the
appropriate "unofficial status level" security evaluation in the process
of converting it to live-git -9999.
Quality:
I /think/ the quality attribute /may/ have been introduced later as IDR
reading about it in the original layman docs, as I think back then the
/assumption/ was that "if it's only in an overlay, it's not up to main-
tree quality", thus "experimental" and possibly incomplete/under-
development, below ~arch-level quality. Either that or perhaps IDR it
simply because it didn't strike me as important enough to "underline in my
memory" like the status did (with the experimental assumption then being
on my part as seeming obvious).
Graveyard would have been the sunset overlay, which I guess has fallen by
the wayside? (Of course I'm personally much more toward the live-git side
than sunset/graveyard, so I'd have never noticed sunset's disappearance.)
FWIW kde's the only overlay I'm currently actively using (for -9999s, sets
and package.accept_keywords), and it's (correctly) official status,
experimental quality. (Tho I only just removed qt days ago, after reading
that qt*-9999s are officially in-tree now -- kde of course having required
it at times for the -9999s in the :5 era due to upstream kde's sometime
dependency on unreleased qt.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2025-03-28 8:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 4:27 [gentoo-dev] The meaning of attributes in repositories.xml? Michał Górny
2025-03-28 8:15 ` [gentoo-dev] " Anna Vyalkova
2025-03-28 8:59 ` Ionen Wolkens
2025-03-28 8:23 ` Duncan [this message]
2025-03-28 13:04 ` Michał Górny
2025-03-28 16:31 ` Duncan
2025-03-30 14:37 ` Gerion Entrup
2025-03-28 11:59 ` [gentoo-dev] " Ulrich Müller
2025-03-28 12:57 ` Michał Górny
2025-03-28 16:51 ` Ulrich Müller
2025-03-28 17:19 ` Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$215dc$6197ae64$428feea5$b0e11aa6@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox