Jeremy Katz wrote:
(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.
I could have it take an environment variable from the outside or read a
FIFO? ;-)
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?
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??).
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.
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 ;-)
Kind regards,
Jeroen van Meeuwen
-kanarip
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
