Re: Fedora 28-20180416.n.0 compose check report

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux