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