[RFC] acct-*/*: destabilize all arches

[falbrechtskirchinger]

After accidentally violating "Rule 4" of the regulations regarding unstable keywords (80c3c45 cdca250) and realizing pkgcheck doesn't cover it, I implemented a new check (pkgcore/pkgcheck#769).

I discovered that most acct-*/* packages fail this new check because they inherit their KEYWORDS from an eclass rather than defining them explicitly.

I am looking for consensus on how to handle this before proceeding:

• Add an exception: We can exempt acct-*/* from this check (there is precedent for this in pkgcheck, but I disfavor this option for being opaque).
• Fix the ebuilds: I have a script ready that inserts KEYWORDS, re-orders SLOTs, and enforces styling, as demonstrated in this patch.
• I'm of course open to any alternative proposals or alterations (e.g., fewer keywords instead of all).

In addition, I'd appreciate feedback on the check itself. After all, I hope for the check to be enabled in ::guru eventually.

[Leo3418]

I agree that this issue is worth attention.

* **Fix the ebuilds:** I have a script ready that inserts `KEYWORDS`, re-orders `SLOT`s, and enforces styling, as demonstrated in this patch.

I'm not saying this is an unacceptable solution, just making a point that such a script would need to be run repeatedly: for example, it would need to be run again when a new keyword for a new architecture is introduced, and when a keyword is completely dropped (e.g., ~ia64 a few years ago). Some automation about the script could be done, like another pkgcheck check for whether every non-live ebuild in acct-*/*::guru includes all ~ keywords in KEYWORDS, so when the check fails at a larger scale (e.g., on all acct-*/*::guru ebuilds), we know the script should be run again.

[falbrechtskirchinger]

I agree that this issue is worth attention.

* **Fix the ebuilds:** I have a script ready that inserts `KEYWORDS`, re-orders `SLOT`s, and enforces styling, as demonstrated in this patch.

I'm not saying this is an unacceptable solution, just making a point that such a script would need to be run repeatedly: for example, it would need to be run again when a new keyword for a new architecture is introduced, and when a keyword is completely dropped (e.g., ~ia64 a few years ago). Some automation about the script could be done, like another pkgcheck check for whether every non-live ebuild in acct-*/*::guru includes all ~ keywords in KEYWORDS, so when the check fails at a larger scale (e.g., on all acct-*/*::guru ebuilds), we know the script should be run again.

Removing a keyword is trivial (a simple sed one-liner), so I am not worried about automation there. My script was mainly a one-off aimed at dealing with VariableOrderCheck and standardizing style.
Adding more is equally easy, once KEYWORDS="" is reliably present, and not strictly required.

My check only enforces that no stable keywords are used.

[gonsoos]

Huh, this is new to me, thanks for the write-up. You should take the discussion to the official means of communication, i.e. the #gentoo-guru IRC channel, bugs.gentoo.org or the gentoo-guru@gentoo.org ML, though. GitHub is not the correct place for this.

My two cents:
I agree that the incongruity between the regulations and the acct* eclass consumers needs resolution. Since this hasn't come up in bugs and users are unlikely to explicitly install these type of packages, I tend to favor amending the regulations. Additionally, setting KEYWORDS in them neither has a precedent in ::gentoo nor does the devmanual page on users and groups mention it, so I expect this to cause additional workload in GURU.

I have my reservations when it comes to the pkgcheck stable check in CI, since this is not an issue in ::guru at the moment*, ignoring the acct* ebuilds, and this feels like prolonging the CI runs for no reason. But I'll wait for a conclusion to the discussion and some actual numbers first.

I have a script ready [...]

Please share that, especially before committing tree-wide changes :) On that note, there's the prevalent ekeyword from app-portage/gentoolkit, which you use to modify the existing KEYWORDS variable in ebuilds.

---

* Diff against repo after ekeyword ~all $(git grep --name-only 'KEYWORDS=' '**/*.ebuild' )

[falbrechtskirchinger]

(...) You should take the discussion to the official means of communication (...)

I will do that in the coming days, thanks.

I have my reservations when it comes to the pkgcheck stable check in CI, since this is not an issue in ::guru at the moment*, ignoring the acct* ebuilds, and this feels like prolonging the CI runs for no reason. But I'll wait for a conclusion to the discussion and some actual numbers first.

Well, the point of CI is to test and enforce standards and practices. I wouldn't say "prolonging the CI runs for no reason" is a fair characterization. 🤷‍♂️

I have a script ready [...]

Please share that, especially before committing tree-wide changes :)

I'm just informing you of the script to say that it's easy to reproduce or modify, and that I didn't waste any significant amount of time on this. Otherwise, the results speak for themselves, don't they? (See file diff.)

On that note, there's the prevalent ekeyword from app-portage/gentoolkit, which you use to modify the existing KEYWORDS variable in ebuilds.

👍

[mgorny]

I also dare say it's better to change pkgcheck than keep overriding KEYWORDS all over the place.

[szczot3k]

While the ::guru regulations stipulate that Stable keywords must not be used. I personally don't believe it should concern acct-*/*, as it's not really a regular 'package'.

As I don't see a documented process of proposing a change to the regulations (cc: mgorny), it's hard to tell what exactly should be done in this matter. I would be however in favor of changing the regulations to account for acct-/ being stable (and possibly documenting that there's no GLEP81-like structure for reserving an ID like in ::gentoo, but other parts of it should be followed as closely as possible).

[falbrechtskirchinger]

My main concern with fixing this inside pkgcheck by ignoring the acct-group and acct-user categories is that it would be opaque and invisible to users. However, there is an effort to make QA checks configurable. Once implemented, these exceptions can be exposed as a configuration option making them user-discoverable.

KEYWORDS in eclasses is a known issue and hasn't received much attention in over 15 years.

As such, I consider this issue resolved as far as the QA check is concerned. However, since other points were raised that merit discussion, I've sent an email to the GURU mailing list to address those broader topics. Thanks for the feedback!