[Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!

[Panu Matilainen]

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 at 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 -