Jeremy Katz wrote:
On Wednesday, January 14 2009, Jeroen van Meeuwen said:
Jeremy Katz wrote:
Do these actually need to be excluded now? I think that with recent yum (which we end up depending on anyway), if you have a package set which includes
fedora-release
generic-release
and then you explicitly specify to install 'generic-release', provides
which generic-release can do will get used "first" and then we'd only
fall back to fedora-release if there was a provide which couldn't be
satisfied.
Well, upd-instroot selects "system-release" and "system-logos", and
let's YUM figure out whatever is the best match. The user (or
application triggering buildinstall) is not able to select the brand
packages.
You're switching the use of system-release and system-logos to be
$brandpkgname-release and -logos, though. I don't see anything left
referring to the system-logos and system-release package. So with the
explicit calling out of a brandpkgname, I'm not sure why we need both
that *and* the excludes
I'm not sure if I understand your concern correctly but I'll try and
answer anyway;
Anaconda doesn't need to use system-logos/system-release to select the
package being pulled in for <brand>-release and <brand>-logos, and
that's not what they were intended for either, if you think of it.
The system-release and system-logos Provides: have been added so that
other packages could have something to require other then requiring a
specific brand package, and not the way we're using them now; selecting
the brand package using a couple of workaround such as |grep -v
generic-logos and the |head -1
The system-release and system-logos Provides that every brand package
has though still helps in resolving the dependencies (and borking if
they can't be met).
Anyway, this is the alternative of a patch sent earlier, with the
--logopkg option to buildinstall. If we like that better (and in fact I
do because it is more flexible to the user/program), I can rebase that
and submit it?
Kind regards,
Jeroen van Meeuwen
-kanarip
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
