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.
Due to (recent) changes in the master branch, I have not yet been able to test this specific changeset but it's derived from what I did against the Fedora 9 branch to make rebranding work. I hope it shows the point of what I'm trying to do and I'll rebase the patch later if necessary. Consider this not yet ready for checkin if you will ;-)
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).
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.
This relates to bugz 457378 and 457379 (although the former had been fixed already), which were created when trying to have foobarbaz-logos be the -logos package for the brand FooBarBaz Fedora derivative.
I think the alternative route is to do fu to the virtual requires/provides mechanism that we have now with "system-logos", and I'm not sure how we could make the one intended (right) package go in that way.
Hope this helps,
Kind regards,
Jeroen van Meeuwen -kanarip
(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
Jeremy Katz wrote:
Seems reasonable, although the need for more options being passed to buildinstall etc is kind of painful. But c'est la vie.
rpm and mkisofs both have the ability to read a configuration file to ascertain local preferences, why not buildinstall?
Presumably, CentOS, Scientific Linux, Fedora and Red Hat don't change their logos all that often. Surely reading a configuration file to get this information is way simpler for the user than having to remember myriad commandline switches! I've been known to write a script just to customise a complex commandline (rsync is another with an overly complicated commandline).
On Aug 27, 2008, at 4:18 PM, John Summerfield wrote:
Jeremy Katz wrote:
Seems reasonable, although the need for more options being passed to buildinstall etc is kind of painful. But c'est la vie.
rpm and mkisofs both have the ability to read a configuration file to ascertain local preferences, why not buildinstall?
Presumably, CentOS, Scientific Linux, Fedora and Red Hat don't change their logos all that often. Surely reading a configuration file to get this information is way simpler for the user than having to remember myriad commandline switches! I've been known to write a script just to customise a complex commandline (rsync is another with an overly complicated commandline).
You think rsync is difficult? Try mkisofs, tar, cpio, or iptables.
I could go on, but that might derail the thread.
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
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@lists.stg.fedoraproject.org