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.
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?
On 16-07-2023 10:57:54 -0400, Matt Turner wrote:
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.
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?
I don't know how widespread the problem is, and how much it can be generalised, but could you perhaps use a virtual, such that
stabilisation of the virtual means the deps must be satisfied?
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.
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?
Thanks,
Matt
On Sun, 16 Jul 2023, Arthur Zamarin wrote:
Let me list some things as advantages to each one (since I see an
advantage to one as disadvantage to other).
Advantages of field in metadata.xml:
- local to package, easier to not miss. Easier to follow for the maintainer.
- easier to find which group the current package relates to
Advantages to group files:
- easier to index (one file listing all children, instead of searching
across repo who defines it)
- easier to not repeat group. In the metadata field it might happen to repeat, less likely since it is easy to search, but similar group names
might be created, merging them into one by mistake, or creating very
similar names and mistaking them. When we have a single file, it is
easier to see the whole picture and verify things.
- since this is compressed information (special files instead of spread
over repo), we could load all of them into app's cache, and make all computation easier.
- enables an easier syntax as `pkgdev bugs @group1` to file a single bug
for all of them. In Gnome's case as an example, we could have "gnome1", "gnome2", "gnome3", "gnome4", etc - groups standing for multiple "layers/stages" of stabilizing, and then you could just file `pkgdev
bugs @gnome{1..4}` to file "at one click" the whole gnome stablereqs.
On Sun, 16 Jul 2023, Arthur Zamarin wrote:
- enables an easier syntax as `pkgdev bugs @group1` to file a single bug
for all of them. In Gnome's case as an example, we could have "gnome1",
"gnome2", "gnome3", "gnome4", etc - groups standing for multiple
"layers/stages" of stabilizing, and then you could just file `pkgdev
bugs @gnome{1..4}` to file "at one click" the whole gnome stablereqs.
Can't we do the same that we do for local use flags? Namely, define them
in metadata.xml, but collect them in one central location?
Ulrich
Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
think both approaches are good, but I would prefer the latter over the former. Nicer syntax, easy cache of all groups, easier to solve the
"graph problems" in the tool.
On Sun, Jul 16, 2023 at 2:04 PM Arthur Zamarin <arthurzam@gentoo.org> wrote:
Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
think both approaches are good, but I would prefer the latter over the
former. Nicer syntax, easy cache of all groups, easier to solve the
"graph problems" in the tool.
Sounds good to me. Should we have infra create a new git repo for us
for this purpose?
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.
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?
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
Hmm, I was thinking the opposite (maintaining it in parallel place to
the package would be harder), but if you say so (and you help maintain
huge clusters of packages so I believe you) then I think we don't have
any good reason to go with per package metadata.xml entry?
On 17/07/2023 16.50, Matt Turner wrote:
On Sun, Jul 16, 2023 at 2:04 PM Arthur Zamarin <arthurzam@gentoo.org> wrote:
Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
think both approaches are good, but I would prefer the latter over the
former. Nicer syntax, easy cache of all groups, easier to solve the
"graph problems" in the tool.
Sounds good to me. Should we have infra create a new git repo for us
for this purpose?
No. I think it should go under normal git repo, and not separate repo. I
see no gains from it being under separate repository, only headache (how
to sync between them).
I think a main index files under
"/metadata/${some_good_name}/${group_name}" would be best.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 491 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 130:47:30 |
| Calls: | 9,690 |
| Calls today: | 6 |
| Files: | 13,728 |
| Messages: | 6,177,507 |