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 -