As I already said on IRC, the following code doesn't work the way you expect it to work: if [[ ${CTARGET:-${CHOST}} == s390x-* ]] ; then SRC_URI="tape3590-2.4.21-s390x-02-june2003.tar.gz" else SRC_URI="tape3590-2.4.21-s390-02-june2003.tar.gz" fi Portage uses the pre-generated metadata cache for fetching. Mr.Bones already removed the unused digest entries. If you want conditional behaviour use flag? style conditionals. luna ~ # CTARGET=s390-foo-bar ebuild /usr/portage/sys-apps/s390-oco/s390-oco-2.6.5.ebuild clean unpack * using s390 >>> md5 files ;-) s390-oco-2.4.21-r1.ebuild >>> md5 files ;-) s390-oco-2.6.5 >>> md5 files ;-) s390-oco-2.6.5.ebuild >>> md5 files ;-) files/digest-s390-oco-2.4.21-r1 >>> md5 files ;-) files/s390-oco >>> md5 files ;-) files/digest-s390-oco-2.6.5 >>> md5 src_uri ;-) tape_3590-2.6.5-s390-april2004.tar.gz * using s390 * using s390 >>> Unpacking source... >>> Unpacking tape_3590-2.6.5-s390-april2004.tar.gz to /var/tmp/portage/s390-oco-2.6.5/work >>> Source unpacked. luna ~ # CTARGET=s390x-foo-bar ebuild /usr/portage/sys-apps/s390-oco/s390-oco-2.6.5.ebuild clean unpack * using s390x >>> md5 files ;-) s390-oco-2.4.21-r1.ebuild >>> md5 files ;-) s390-oco-2.6.5 >>> md5 files ;-) s390-oco-2.6.5.ebuild >>> md5 files ;-) files/digest-s390-oco-2.4.21-r1 >>> md5 files ;-) files/s390-oco >>> md5 files ;-) files/digest-s390-oco-2.6.5 >>> md5 src_uri ;-) tape_3590-2.6.5-s390-april2004.tar.gz * using s390x * using s390x >>> Unpacking source... >>> Unpacking tape_3590-2.6.5-s390-april2004.tar.gz to /var/tmp/portage/s390-oco-2.6.5/work >>> Source unpacked. luna ~ #
Spanky, do something about this lest it be removed... not valid, nor will it work for those on rsync. So... why is it in the tree?
Can we please get this fixed? Either via a USE flag or just remove it. It won't work at all like it is intended for rsync users as it is.
There were no objections to adding PROFILE_ARCH to the expand list. Any reason s390 can't use this solution rather than the current broken method?
(In reply to comment #3) > There were no objections to adding PROFILE_ARCH to the expand list. Any reason > s390 can't use this solution rather than the current broken method? > Do you have a link to the discussion? OSX has a similar problem and we may end up fixing it in a similar manner.
http://marc.theaimsgroup.com/?l=gentoo-dev&m=113973633613749&w=2 For the original PROFILE_ARCH justification, you'll need to go back approximately four years. It was supposed to be in expand from the beginning, but no-one quite got around to it then.
(In reply to comment #5) > http://marc.theaimsgroup.com/?l=gentoo-dev&m=113973633613749&w=2 > > For the original PROFILE_ARCH justification, you'll need to go back > approximately four years. It was supposed to be in expand from the beginning, > but no-one quite got around to it then. > Nah, I groke it, but people with USE="-*" will get it waxed, which is why I think we should inject it into USE similarly to how ARCH is injected. Thoughts?
USE_EXPAND should be of higher priority than USE="-*"...
(In reply to comment #7) > USE_EXPAND should be of higher priority than USE="-*"... > That only works as long as USE_EXPAND isn't abused. USE="-*" probably shouldn't kill KERNEL, LIBC, and USERLAND expands, but it may need to kill other EXPANDS in the future. A bad example would be someone setting LINGUAS in a profile or something. Since anyone can add to USE_EXPAND at any time, and these are not removed by USE="-*", how would you limit their use in this case? Beat on people who commit stupid things to profiles?
(In reply to comment #7) > USE_EXPAND should be of higher priority than USE="-*"... > Ok I lied, it does ;)
(In reply to comment #3) > There were no objections to adding PROFILE_ARCH to the expand list. Any reason > s390 can't use this solution rather than the current broken method? > Also looking at adding a mechanism to forcing flags on, but there is no patch for this yet. And by forcing, I mean you need to make a use.unforce file ( or equivelant ) to turn them off. ARCH and USERLAND are currently exceptions in the current scheme of things, and we'd like to normalize that behavior.
This has been fixed, thanks Spanky.
