On Tue, 2014-10-28 at 15:27 -0600, Chris Murphy wrote:
OK yeah, this sounds rather dire at the end, but is beyond confusing…
x requires x, y requires y, z requires z. Umm what?
WARNING: problems were encountered during transaction test:
broken dependencies
NetworkManager-wifi-1:0.9.10.0-5.git20140704.fc21.x86_64 requires
NetworkManager-wifi-1:0.9.10.0-5.git20140704.fc21.x86_64
NetworkManager-adsl-1:0.9.10.0-5.git20140704.fc21.x86_64 requires
NetworkManager-adsl-1:0.9.10.0-5.git20140704.fc21.x86_64
NetworkManager-wwan-1:0.9.10.0-5.git20140704.fc21.x86_64 requires
NetworkManager-wwan-1:0.9.10.0-5.git20140704.fc21.x86_64
NetworkManager-bluetooth-1:0.9.10.0-5.git20140704.fc21.x86_64 requires
NetworkManager-bluetooth-1:0.9.10.0-5.git20140704.fc21.x86_64
Continue with the upgrade at your own risk.
So I believe I have a theory for what's going on here, and it's kind of
fun. The point of instrepo is to provide a repo for fedup to get the
upgrade.img from, but I suspect it also uses it as a package repository.
So this is caused by the packages we 'pull' into composes. The
instructions say to use the current compose's Server tree as the
'instrepo' - because that's how we can test the 'correct' upgrade.img
for the compose. However, that tree also has a package repository. The
packages in that repository are *mostly* the same as the packages in the
'fedora' (stable) repository, but not quite. The compose trees are the
trees used to build the images, right? So obviously, when we 'pull'
packages that are not yet stable but which fix blocker/FE bugs into the
compose requests, they get pulled into those trees.
So if you look in
https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC1/Server/x86_64/os/P...
you'll see it has the packages that are being 'pulled' into the composes - the
packages from
http://kojipkgs.fedoraproject.org/mash/bleed/ .
However, it's not a *complete* package repository. It only contains the
packages needed to compose the Server DVD, because after all, that's
what the tree is ultimately *for*. Have a look in
https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC1/Server/x86_64/os/P... and
you'll see it doesn't have...all those NetworkManager sub-packages your fedup run
complains about. No wifi, no adsl, no wwan, no bluetooth. Reason being, those packages
aren't in the Server package set.
Now, NetworkManager is one of the packages we're 'pulling' into composes
- we 'pull'ed 9git20140704 to fix the weird dep chain issue which caused
32-bit Workstation TC4 not to boot. So ultimately, fedup has a problem.
It has 9git20140704 builds of half the NetworkManager packages, from
https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC1/Server/x86_64/os/P... , but
it doesn't have 9git20140704 builds of the rest, because they're not in any repo
it has enabled (they'd be in updates-testing, but that won't usually be enabled on
an upgrade from a stable release). It wants to upgrade the packages that *are* in Server
to 9git, but then it can't find matching versions of the subpackages you have
installed that are *not* in Server.
This shouldn't be a huge issue for non-testers because by the same we
release a milestone build we always try to have the packages that were
'pulled in' marked as stable properly, so people shouldn't encounter
this. It's likely to be a somewhat regular occurrence for TC/RC testers,
though, so long as we don't have an Everything tree with upgrade.img in
it. Enabling updates-testing should always avoid it, I think (unless
we've 'pulled' in a build which hasn't even made it to u-t yet, which
occasionally happens), though of course it means you won't be testing an
upgrade to the current 'stable' 21 package set.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net