On Tue, 2005-11-29 at 16:24 +1100, Alan Milligan wrote:
> One thing that really frustrates me about anaconda is that it's splash
> screen generation sucks -at least for anaconda <= FC4 - I'm not enough
> of a masochist to try the latest devel packages ;)
Bah, they even mostly work right now ;-)
> system-splash.png is located in fedora-logos (or redhat-logos). When
> creating a Linux derivative distribution, the first thing we do is
> create a new -logos package (the second thing is a new -release package).
>
> However, upd-instroot hard-codes redhat-logos and fedora-logos into it's
> packages and thus does not unpack our -logos and then barfs when
> system-splash.png is not found.
We should probably just move the package to be named system-logos
similar to other packages. Then it's much more generic.
> What I'd like to see instead, is something similar to the tzdate logic,
> where it checks through the %{PROVIDES} to discover this (maybe look for
> provides redhat-logos).
The tzdata package is actually strange. I honestly can't see from a
quick look what we're gaining by doing them like that. The same thing
should be accomplished with just adding the dirs to the filelists and
using the normal package expansion. I'm sure there used to be a good
reason for doing it like this, but I don't remember what it was at the
moment.
> At the moment, we have to cut new anaconda packages for each derivative
> - - with this change, we wouldn't need to. Another less glamorous option
> could be to pass this as a parameter to buildinstall, but I'd prefer to
> use the knowledge contained in the RPM's.
>
> Anyone care to comment? Any chance of getting this into FC5?
Eventually, we need to sit down and probably rework the entire way that
upd-instroot works. It's getting to be pretty crufty :) That's not
going to happen for FC5, though. I went ahead and did the quick change
so that a package named 'system-logos' is acceptable also. Hopefully
that should help a bit.
Jeremy
