(Sorry for the lag, last week was the obvious problems and then I went on vacation :-) On Mon, 2008-08-18 at 18:41 +0200, Jeroen van Meeuwen wrote: > This is a patch that enables choosing a specific -logos package rather > then having dependency resolving pull in a package, and using it to > build the installer images which usually show whatever logos used, > everywhere. Seems reasonable, although the need for more options being passed to buildinstall etc is kind of painful. But c'est la vie. > The package sack for an initialized yum object is mostly populated with > more then one -logos package. Which of these packages is going to > satisfy the "system-logos" dependency is (at this moment at least) at > best an educated guess (Provides:, Obsoletes:, Conflicts: and/or a > significant NEVRA bump don't seem to help). Is having the logo package we want in the transaction set (listed in PACKAGESGR) not good enough? I know that at one point it wasn't, but I'm pretty sure I saw a commit from jantill to yum so that we'd try to satisfy deps from packages already in the ts first. That might mean depending on yum 3.2.19, but that's okay for master. > The patch let's one specify a specific -logos package using --logopkg to > the buildinstall script, which then excludes a certain set of other, > known -logos packages by means of adding a list to the "exclude=" > parameter in the $yumconf used, and let's $LOGOPKG be used whereever > possible. The big worry I have here is that someone else will have another -logos package (centos-logos anyone? :) and then we'll get bitten by not having a complete list. So it seems better to make it an "include this package" as opposed to "exclude these other packages" type of thing. Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list