FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Laptop

 
 
LinkBack Thread Tools
 
Old 08-18-2008, 04:41 PM
Jeroen van Meeuwen
 
Default Choose logos package

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
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 08-27-2008, 04:30 PM
Jeremy Katz
 
Default Choose logos package

(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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 08-28-2008, 02:18 AM
John Summerfield
 
Default Choose logos package

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).



--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 08-28-2008, 02:23 AM
David Cantrell
 
Default Choose logos package

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.

--
David Cantrell <dcantrell@redhat.com>
Red Hat / Honolulu, HI

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 09-07-2008, 08:01 AM
Jeroen van Meeuwen
 
Default Choose logos package

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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 09-08-2008, 01:25 AM
Jeremy Katz
 
Default Choose logos package

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

Thread Tools




All times are GMT. The time now is 10:34 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org