Re: [gentoo-dev] Package stabilization groups

[Sam James <sam@gentoo.org>]

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


Matt Turner <mattst88@gentoo.org> writes:

> Hello,
>
> Many of us have started using `pkgdev bugs` to file stabilization
> bugs. It works well (Thanks Arthur!) and I encourage everyone to give
> it a try.
>
> Where possible, it files one stabilization bug per package. This makes
> arch testers' jobs easier and makes the task easier to automate.
>
> But sometimes we do want to stabilize packages together. For example
> major versions of x11-wm/mutter and gnome-base/gnome-shell are tied
> together. If a new mutter is stabilized without the new gnome-shell,
> the tree will still be consistent, but emerge -u @world will warn
> users that the mutter upgrade is blocked.
>

Big fan of the idea & very much in support of it. This also serves
to give us logical groupings of packages which are closely related
and should be bumped together.

> There was some brief discussion on IRC about how to document these
> groupings, and two main ideas were suggested:
>
> - add a field to metadata.xml to specify the group by an arbitrary name.
>   E.g. <stable-group name="..."/>
>   Each package in the group would specify the same value of name="..."
>
> - maintain the groups in a separate place (similar to portage @sets).
>
> Can anyone think of particular advantages or disadvantages to one
> solution versus the other? Any other (better) ideas?
>

When we discussed this a few months ago on IRC, I also brought up a
related point:

[2023-05-02T18:38:51+0100] <@sam_> do we want to repeat the group members in each member, or do tools need to scan for each thing?
[2023-05-02T18:39:07+0100] <@sam_> i.e. does each member have <stable-group><pkg>...</pkg></stable-group>, or do we do <stable-group name=".../>?
[2023-05-02T18:39:26+0100] <@arthurzam> I think each package says which groups it is part of
[2023-05-02T18:39:44+0100] <@radhermit> I would do the latter
[...]
[2023-05-02T18:42:42+0100] <@radhermit> technically you could also maintain them in a separate place like metadata/groups and layer inter-group dependencies on top of that somehow in the format

I'd prefer the metadata/ at repo root idea because I can see updating
various metadata.xmls being a nuisance.

best,
sam


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]