Bugzilla Bug 185956

You are using cobalt in SRC_URI but not in IUSE.

dev-lisp/sbcl-1.0.6-r1: attr(fetchables) uses unstated flags [ cobalt ]
dev-lisp/sbcl-1.0.6-r2: attr(fetchables) uses unstated flags [ cobalt ]

it is to distinguish mips from mipsel binaries. There is no official keyword
that does this, so we have to use this kludge. Just like other keywords it
shouldn't be in IUSE, so I intentionally left it out.

(In reply to comment #1)
> it is to distinguish mips from mipsel binaries. There is no official keyword
> that does this, so we have to use this kludge.

That's fine, then stick it in IUSE.

> Just like other keywords it shouldn't be in IUSE

This is not a keyword, it's a USE flag; as such it belongs in IUSE as it is the
case with the remaining ebuilds:

# euse -i cobalt
global use flags (searching: cobalt)
************************************************************
no matching entries found

local use flags (searching: cobalt)
************************************************************
[-    ] cobalt (dev-lisp/sbcl):
mips only: use mipsel binary instead of mips big endian binary to bootstrap

[-    ] cobalt (sys-boot/arcboot):
Disables support for Cobalt Microserver hardware (Qube2/RaQ2)

[-    ] cobalt (sys-kernel/mips-headers):
Enables support for Cobalt Microserver hardware (Qube2/RaQ2)

[-    ] cobalt (sys-kernel/mips-sources):
Enables support for Cobalt Microserver hardware (Qube2/RaQ2)

it is an unofficial arch keyword, nobody should enable or disable it.

Please, could you have a look at the ebuilds mentioned above (and for that
matter,  at any other ebuilds that have ip27, ip28, or ip30 USE flags as well?
All USE flags used in an ebuild belong to IUSE. Whether users should or should
not enable or disable them is irrelevant. I don't see any reason why
dev-lisp/sbcl should be special and break policy.

I don't want it showing up anywhere that x86, amd64, ppc, mips etc don't show
up. Nobody need see it is there and nobody needs to care about it. I'm not
claiming SBCL is special. What I am claiming is that policy is that keywords
should not be in IUSE and cobalt is (used as) a keyword in this and probably
the other cases.

Well, sending this to QA then, this doesn't go anywhere. If you want to be it a
keyword, then make it so w/ MIPS folks (ditto for the rest of 'keywords'
mentioned above. Until it's a keyword, it's a use flag that belongs to IUSE.

Marijn - please put the cobalt edits back the way they were.  The way the
ebuilds currently are is just plain wrong.  Thanks.

No, there is no reason for the Arch flag to clutter up the use flags,
especially not while its main arch is broken and unkeyworded.

(In reply to comment #8)

You know, I talked with Redhatter about this and they specifically *want* these
flags *visible* on non-mips profiles as well because of cross-compile purposes.
You instead decided to break it once again once Redhatter fixed this two weeks
ago. Please revert your broken commit that's in breach of policy, it's getting
really annoying.

Redhatter should talk to ME if he has anything to say about this.

Further there is no way cross compilation works at all with the ebuild.

(In reply to comment #10)
> Redhatter should talk to ME if he has anything to say about this.

Please, read the fine devmanual, cobalt is NOT an arch flag no matter how much
you wish it was one, and there's zero valid reasons your ebuild should be
special (cf. Comment #2, Comment #4)

http://devmanual.gentoo.org/ebuild-writing/variables/index.html
cat $PORTDIR/profiles/arch.list

This is getting old. QA, please fix the ebuild, this debate goes nowhere.

Instead of the use flag it is probably possible to use toolchain-funcs.eclass
to determine the endianness of the mips arch with the tc-endian function.

(In reply to comment #12)
> Instead of the use flag it is probably possible to use toolchain-funcs.eclass
> to determine the endianness of the mips arch with the tc-endian function.

No, you totally can't use toolchain-funcs.eclass in SRC_URI, please stop being
silly and stick the flag back.

(In reply to comment #7)
> Marijn - please put the cobalt edits back the way they were.  The way the
> ebuilds currently are is just plain wrong.  Thanks.
> 


Please fix this now.  It should be in IUSE.  This is the same as the IP28, 
ip32r10k, etc USE flags which all get put into IUSE.

Thanks

If anyone's looking for a clean solution to this... Bring back PROFILE_ARCH,
call it something less silly like SUBARCH and USE_EXPAND{,HIDDEN} it. It'll
still need to be in IUSE (as subarch_cobalt), but it'll be hidden from end
users.

(In reply to comment #15)
> If anyone's looking for a clean solution to this... Bring back PROFILE_ARCH,
> call it something less silly like SUBARCH and USE_EXPAND{,HIDDEN} it. It'll
> still need to be in IUSE (as subarch_cobalt), but it'll be hidden from end
> users.
> 

That sounds like an idea for a longer term solution, but right now it has to go
back into IUSE like it is for arcboot, mips-headers, and mips-sources.

Fixed.  If you would like to pursue the solution that Ciaran gave below, please
open a new bug so it can be discussed.

Thanks