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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
