On Fri, 15 Nov 2013 13:45:29 -0800 Matt Turner <[email protected]> wrote:
> On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman <[email protected]> > wrote: > > On Fri, 15 Nov 2013 13:21:53 -0800 > > Matt Turner <[email protected]> wrote: > > > >> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman <[email protected]> > >> wrote: > >> > On Fri, 15 Nov 2013 12:25:47 -0800 > >> > Matt Turner <[email protected]> wrote: > >> > > >> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman > >> >> <[email protected]> wrote: > >> >> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag > >> >> for kbproto but was attempting to emerge unstable (or unmasked > >> >> abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that > >> >> abi_x86_32 is masked), unmerge kbproto and attempt to emerge > >> >> libXt: > >> >> > >> >> [...] > >> >> > >> >> emerge: there are no ebuilds built with USE flags to satisfy > >> >> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]". > >> >> !!! One of the following packages is required to complete your > >> >> request: > >> >> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32) > >> >> (dependency required by "x11-libs/libXt-1.1.4" [ebuild]) > >> >> (dependency required by "libXt" [argument]) > >> >> > >> >> It suggests that I turn off abi_x86_32 for libXt rather than > >> >> telling me to turn the flag on for kbproto! > >> > > >> > Why should it literally suggest you to do something known to be > >> > broken? > >> > >> I don't know what you mean. kbproto[abi_x86_32] isn't known to be > >> broken. You're asking a really weird question based on some > >> implicit context that's not available to me. > > > > A mask implies something is broken (or experimental). > > Then to answer your previous question: it would suggest it [something > broken, according to you] because you've asked for something broken > that depends on it! Because a maintainer or achitecture team forgot to cover that case and didn't check on reverse dependencies, which is another case; but even in this case Portage handles well, as it suggests to step away from the brokenness. > >> I'm claiming in this example that attempting to emerge > >> libXt[abi_x86_32], portage should tell you that abi_x86_32 should > >> be set for kbproto, rather than telling you to unset abi_x86_32 > >> for libXt (which you're requesting to be emerged, damn it!). > > > > You have to be explicit when you want broken (or experimental) > > things; just emerging it isn't enough, taking a step further than > > that is. > > I'm explicitly saying that I want libXt with USE=abi_x86_32. > Suggesting that I turn it off is kind of ridiculous, don't you think? In your case, yes. In general, no; if you suggest to do this to anyone instead of just the small few that want it, it would encourage people to override what we mark as broken and that is a recipe for disaster. > This seems pretty clear cut. Are you just jerking me around now? For your case it could be made better, but as this very same output gets the eyes of people with other intentions; we can't just outright apply it that way and break systems, we have to satisfy most parties. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
