On 11/11/2012 06:35 PM, Adam Williamson wrote:
On 2012-11-11 0:53, Panu Matilainen wrote:
Reverting mini-debuginfo would require a mass-rebuild which is hardly
going to happen at this point of F18 no matter what you think of the
feature.
For starters it would help if the DVD didn't contain piles of
obsoleted, conflicting and in some cases (at least samba), duplicate
versions of packages:
[root@turre rpm]# ./rpm -Uvh --test --root /home/test/ --nosignature
~pmatilai/mft/f18-dvd-all.mft
This is a bad test and is not intended to be possible. There are various
reasons why such packages end up on the images. Some are bugs, but some
are not.
Sure its a stupid test, a truly everything-install from a repository is
not a meaningful operation. On a space-constrained media it does at
least point out some suspect issues.
warning: package grub-1:0.97-91.fc18.x86_64 was already added,
replacing with grub2-1:2.00-12.fc18.x86_64
This was the case at least for a long time because we used grub on some
platforms and grub2 on others. I'm not sure if we're still using grub
for anything on F18, but we may be. I'm on my laptop where I don't have
an anaconda checkout handy to check.
Bootloader differences between architectures I can understand, but
within x86_64 DVD?
I don't have specific knowledge of the others, but some are obvious -
there's a couple of packages which conflict explicitly, which is fine.
You're not supposed to be able to install all of the DVD at once, but
different bits in different situations.
The other classic case is that when a dependency of a package in the set
of packages to be included in an image is satisfied by more than one
other package, pungi pulls *all* the satisfying packages into the
compose, not just one. This seems odd at first glance but not at second
thought: it's possible for yum to make a guess at which one should be
pulled in on a specific system - I think the rule it uses is 'causes the
least amount of extra other dependencies' - but pungi can't do that,
because it doesn't know what your eventual installed system is going to
contain! If A requires foo, which is provided by GNOME-B and KDE-C, then
pungi needs to include both on the DVD if it's including A, because on a
GNOME install you'll probably wind up with the dependency fulfilled by
GNOME-B, but on a KDE install you'll probably want to have it fulfilled
by KDE-C. If we only pulled in GNOME-B to the DVD, a KDE install might
look odd. (Just a theoretical example, but you get the point).
Sure there are ambiguous cases - between identical providers and
mutually conflicting packages there's no telling what should be pulled
in. But most of these cases seem like one-way obsoleted packages, and
there's not a whole lot of point installing packages which will get
replaced on the first 'yum update' you ever do on the installed system.
Such as sysklogd. Or grub on x86_64 - if there are architectures where
grub2 cannot be built then it wont exist and wont obsolete anything
either, but on x86_64 it'll just get replaced by grub2 immediately.
What's the script/tool used to compose the images these days?
pungi, but please consider the quirks of what it's doing before
concluding that it's broken.
Ah, pungi, of course. I know I knew that, only had forgotten... thanks :)
Based on a quick grep, it doesn't seem to consider obsoletion at all,
which explains what I see on the DVD and perhaps deserves looking at.
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
