Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4675 bytes --]

On Fri, 15 Nov 2013 13:21:53 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> > On Fri, 15 Nov 2013 12:25:47 -0800
> > Matt Turner <mattst88@gentoo.org> wrote:
> >
> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman <TomWij@gentoo.org>
> >> 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).

> 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 not sure if making broken (or experimental) things more easily
available or a suggestion would be a good idea; people already have
enough trouble as it is, adding more doesn't seem to be the right way.

> > It is clear from the output how it wants the dependency to be; so,
> > if you want to do something different, you can and the output tells
> > enough.
> >
> > Due to the complexity of the dependency, you will need `man 5
> > ebuild` though; (-) means to assume it as disabled if it doesn't
> > exist.
> >
> >> Portage prints other things intelligently:
> >>
> >> mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
> >>
> >> These are the packages that would be merged, in order:
> >>
> >> Calculating dependencies... done!
> >>
> >>
> >> [nomerge       ] dev-python/py-1.4.13  USE="{test}"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)"
> >> [ebuild  N     ]  dev-python/pytest-2.3.5  USE="{test} -doc"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)" 417 kB
> >> [ebuild  N     ]   dev-python/py-1.4.13  USE="{test}"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)" 185 kB
> >>
> >> Total: 2 packages (2 new), Size of downloads: 602 kB
> >>
> >>  * Error: circular dependencies:
> >>
> >> (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends
> >> on (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
> >> (buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
> >> merge) (buildtime)
> >>
> >> It might be possible to break this cycle
> >> by applying the following change:
> >> - dev-python/py-1.4.13 (Change USE: -test)
> >>
> >> Note that this change can be reverted, once the package has been
> >> installed.
> >
> > This is just like how you can't compile gcc without having compiled
> > gcc with another compiler first (or used a binpkg, or obtained from
> > stage3); thus, similarly, you can't test py without having pytest
> > first etc...
> 
> I don't think you understood my intention for giving this example.
> Portage correctly figures out the proper solution and suggests it. I'm
> saying that this is a good thing.

Now the question is whether this is or isn't an opposite example;
because it might very well be intelligent, that doesn't mean that the
other example isn't intelligent. As we trying to make that clear, this
example doesn't really fit; so, I didn't assume it to be opposite.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]