Re: [PATCH] Choose logos package

[Jeremy Katz <katzj redhat com>]

On Sun, 2008-09-07 at 10:01 +0200, Jeroen van Meeuwen wrote:
> Jeremy Katz wrote:
> >> 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.
>
> That's the system-logos entry in what is $PACKAGES now, that'll pull in 
> /a/ logos package, right?

Yes -- but if we switch it to $LOGOPKG being listed in PACKAGES, that
will be the one pulled in

> I guess part of the problem is that it's not just the 'composed tree' is 
> a source for rpms needed for buildinstall so we can only assume that all 
> of fedora-logos, generic-logos, centos-logos and foo-logos are 
> available. I guess the trick I'm trying to perform is to be able to 
> choose any random package (scientific6linux-logos, 
> orangesombrero-logos), one of those packages or fall back to a default 
> (maybe the default should be derived from the product name and then fall 
> back to generic-logos??).

That should work though if we use $LOGOPKG in $PACKAGES

> >> 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.
> 
> Not really, because upstream provided logos packages are fedora-logos, 
> generic-logos and redhat-logos. If any other package is chosen, these 
> should be excluded from the yum repositories used. In the case of 
> CentOS, I guess none of these packages exist in the repositories they 
> use to compose against, and if it does (include generic-logos for 
> example), --logo-pkg centos would do the trick.

If I'm building a derived distribution based on a derivative, then there
is easily the possibility of further logo packages.  Eg, something based
on CentOS.

> >   So it seems better to make it an "include this
> > package" as opposed to "exclude these other packages" type of thing.
> >
> I'm sure that including a package (using includepkgs=) is going to 
> impact the rest of the buildinstall process. However, using an exclude 
> might look more like exclude=*!($product-or-chosen-logospkg)-logos, but 
> I'm not sure I can get that to work just like that ;-)

Not using includepkgs= -- instead switching to specifying the logo
package instead of just system-logos.

Jeremy