Re: [gentoo-dev] "Lazy" use flags?

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/09/2016 04:27 AM, Kent Fredric wrote:
> There's a frequent irritation I experience with the revolving door
> of REQUIRED_USE -> auto-unmask:
>
> There's no mechanism in place to automatically stop using a
> "REQUIRED" use flag when it ceases to be necessary.
>
> So you find yourself doing things like:
>
> - I want X - X only supports python 2.7 - X thus requires a
> dependency that supports both 2.7 and 3.5 to set USE= for python
> 2.7 - So you add a USE in your package.use for that dependency. -
> This creates a cascade of requiring python 2.7, sometimes
> extending to pull extra dependencies for back-ports.
>
> Later, X adds Python 3.5 support.
>
> And now you have redundant USE flags in place, and those USE flags
> pull in dependencies you no longer need in order to support a
> python 2.7 featureset.
>
> Now, this is not about "python", this is just the general pattern
> of ebuilds saying "I need this", and then requiring me to manually
> acknowledge "I need this" when I don't actually want this myself,
> similar to how packages "I need" go in the world file and don't
> get depcleaned, and packages I "don't need" are handled by portage
> automatically satisfying dependencies.
>
> And you have to invest a respectable amount of effort to prune
> these un-needed dependencies and features which portage now thinks
> "you want", even long after the reason for that is gone.
>
> What I'd like is a middle ground, a USE specification that can be
> stated in package.use that portage interprets as a "permission to
> enable" flag, a USE flag that is treated as "ON" if any dependency
> states it needs it on, and that is treated as "OFF" as soon as
> there are no dependencies in the graph that need it on.
>
> Or vice versa.
>
> Naturally, this needn't be part of PMS, because this pertains to
> nothing about the package dependency specification itself, only a
> feature for user convenience in the portage interface.
>
> I would love to be able to stop maintaining my reasonably large set
> of package.env tricks which I have to regularly update so that
> things I don't need will get expunged when I cease to need them,
> and I'd love to be able to say something like
>
> PYTHON_TARGETS="python3_5 python2_7?" and have portage treat the
> former as "always on" and the latter as "On if a dependency or
> REQUIRED_USE constraint indicated it was needed".
>
> Though it may not be so straight forward to implement, and is
> likely to complicate backtracking.... though in theory it could
> make things simpler.
>
> So I table this query to the dev ml in the event somebody else
> sees merit in the idea.
>

This is an interesting request, and if it was implemented correctly,
could reduce the number of blockers we see. It's almost like automatic
USE flag resolution.

The problem I see is syntax. I'm not 100% familiar with portage's
internals, so I don't know what sort of effects this would have across
an entire depgraph or resolution, etc. But it could be very useful.

Another concern, though, is it'd result in something similar. Instead
of "cat/foo bar baz" and later removing 'baz', you'd have "cat/foo bar
~baz" (with '~baz' as 'enable this if you need to'). You'd still have
cruft left in your p.use file, and it would achieve the same result as
a well-commented file.

I've personally taken to creating little "blocks" of USE flags, even
if redundant, and adding a comment just above them explaining why I
add them. It's not perfect, but if I get curious and check back on it,
I'll always know why I added it.

A possible solution to the file issue is some way of letting the user
know prior to merging that a "lazy" USE flag was specified that's no
longer needed. That could be somewhat easy to implement, as it would
merely check REQUIRED_USE and compare it against any lazy flags. If
they match, show the message.

Regardless, I think it's a neat idea. I'm just not sure if it'd be
something easily implementable in portage/emerge.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWueZFAAoJEAEkDpRQOeFwDxcP/AhRuCsjXm9jjEhT1vfagj9t
7imcFj6czggxBno9Bg5lZFkkU80lPG56wTq6MHAMF7DSwj3HxW1dwLbQSSqQHCLJ
5VzqXM74h5v4TBK24Fq5ht+sN6U3uO5JmaCv2qXg3xiWu34AapdVsCHq+JO2ew/y
quIF18TmpdGbRpnzyXCkdySvqI8GfJYVrFXJsvNN/2H0qgTmS5LQsnqxP6hGhHkc
4qg+GQ4cm5JpLNBo58F+2j2c8kXpicZ4cHMk2RCbX/Hv8u/qsNtYcYcAlsOxJVUP
0iEVlPboQKMQMdK0Mpbhp/Tok1ydpqErXRwijFs5uB249RmeqniWgNbSJtoHZQh1
49VA6fmRo422UaYKb7ZqTK01fSuvC3nRWr3HT/XSb5B4+OrqPUkM7DyElkvBZuQu
YJM2QlmBJ/16XjIwVB6hcS5K/PxvPD+9mU5weyVVTSLjcNHDPMq+K7Gunwn/0Rji
spBTzZQvFfRtiiufIQIWIWIampfNaTMIWEC5CoLSRstxse9w+Qvn+dPd7XCgfpOt
qvF4Qlc715oiGIwF/rGSEq8HHNsW7ZP5YozHTD9Wa7sxl0WxFJWfYJiQ9o7Lclxu
2EldNk1DNWiC4SQA2haEm64KrSFHfrT/3RZ3XPDBl2iaTrn2NAo5abJJGLZuCmtZ
GdcbzDhYKeZJBH4ZOI2U
=x47s
-----END PGP SIGNATURE-----