On Tue, 2018-04-17 at 14:18 -0400, Matthew Miller wrote:

On Mon, Apr 16, 2018 at 05:06:20PM -0700, Adam Williamson wrote:

...

That's a vital dependency for GNOME - gnome-settings-daemon, gnome- session, mutter, nautilus, control-center etc. all depend on it.

[...]

...

So thanks to good old: https://bugzilla.redhat.com/show_bug.cgi?id=1427365 we get images with those packages silently omitted due to the dependency issue. Network installs of the Workstation package set also silently omit these packages. Of course, both of these now don't boot to GNOME, since all the key bits of GNOME are missing.

Where's the earliest point we could detect these issues? Fixing that issues so composes fail loudly rather than just silently being wrong would be better than what we're getting, but it seems like it'd be even better to catch the problem before even getting to that point.

That's a rather interesting question, actually. I think Dusty is interested in doing something along these lines.

Very roughly the scope of the job, leaving out a lot of awkward little details, is to parse fedora-kickstarts and fedora-comps and figure out whether we'd have dependency issues in any of the packages that would actually get pulled into any of the images if we ran a compose 'right now', based on the groups specified in comps and which groups are pulled into which images by the kickstarts.

One problem I can think of is that we might need to have the repo generation phase of the compose done before we can really do this check, because we may need to actually have the repos the image composes will be done from in hand, we might not be able to reliably 'predict' what would actually be in those repos - I don't know how feasible it is to write a thing which tells you "OK, right now if we ran a compose, its repos would contain exactly <THESE PACKAGES>", yet which is still not (and is simpler than) the thing that actually *produces the repos* (i.e. this is a bit of a "the map is the territory" problem).

This case is actually a good example of a subtle case in that process: the broken dependency showed up because a package got *retired*. It wasn't as simple as a straightforward update introducing the issue.

In theory blocking updates on rpmdeplint should be helping us with this (for cases that *are* caused by package updates, at least), as it should prevent updates introducing new dependency issues. But of course, currently issues can be waived very easily, and Rawhide isn't blocked on anything yet. And I'm not sure whether that test is actually 100% accurate; I always forget the details, and I don't know exactly how it's configured right now, but we've had the problem in the past, for instance, that the test ran on 'all of updates-testing', and all of updates-testing was no less internally consistent than before, but then only *some* of the updates pending get pushed stable, and it turns out they depended on *other* updates which didn't get pushed stable at the same time, so it turns out that there actually *is* a new dependency issue in the new stable package set...

OK, so the answer is "it's complicated". :P