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

[Rich Freeman]

On Thu, Feb 11, 2016 at 8:26 PM, Daniel Campbell  wrote:
> Ah, I think I see what you mean now. That's actually a bit more
> predictable and requires less action on behalf of the user. I'd like
> to add that, if we do this, could Portage output which USE flags were
> being automatically added? We already have USE changes indicated with
> the % suffix, would that be enough in your opinion?

It might not hurt to have portage display some kind of prefix that
means the flag is enabled implicitly.  That could be useful whether it
is changing or not.

In any case, none of this will happen unless somebody builds it.  :)

Maybe toss in mix-in support while we're at it.  :)

-- 
Rich

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/11/2016 05:23 PM, Rich Freeman wrote:
> On Thu, Feb 11, 2016 at 7:12 PM, Daniel Campbell 
> wrote:
>> 
>> No, lazy USE in this discussion is akin to installing, say,
>> Steam. That requires a lot of packages that must be rebuilt with
>> abi_x86_32. In such a situation, if there was something like
>> USE="~abi_x86_32" (the ~ is just a symbol, it wouldn't have to be
>> that exact symbol), then packages that need that USE flag would
>> automatically use it, and those that don't need it wouldn't be
>> built with it.
> 
> Actually, I was proposing that you'd only need USE="~abi_x86_32"
> if you set USE="-abi_x86_32" someplace else.  Adding a ~ would
> just remove any previous settings - it wouldn't cause a use flag to
> be turned on or off.  You could have a flag like that even without
> lazy use flag support - it could be used to cause a single package
> to revert to its default use flags.  I'm not really sure if it is
> a terribly useful feature at all.
> 
> In my proposal you wouldn't need to do anything at all on a
> default profile to have USE="abi_x86_32" enabled for packages that
> had that use dependency in some other package.  Just running emerge
> steam would cause rebuilds on anything that didn't already have
> 32-bit support which required it.  You'd only need to mess with
> your flags if you had explicitly set USE="-abi_x86_32" - which
> makes sense since you've now given portage two contradicting
> directives.
> 
> Just as you don't need to do anything special to have "emerge 
> chromium" pull in libX11, you wouldn't need to do anything special
> to have "emerge chromium" cause hwids to rebuild with USE=usb if it
> isn't already built that way, unless you had explicitly set
> USE=-usb.
> 
> And of course this should be something that can be turned off, and 
> users can always run -pv to see what portage is going to do.
> 
Ah, I think I see what you mean now. That's actually a bit more
predictable and requires less action on behalf of the user. I'd like
to add that, if we do this, could Portage output which USE flags were
being automatically added? We already have USE changes indicated with
the % suffix, would that be enough in your opinion?

- -- 
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

iQIcBAEBCAAGBQJWvTS0AAoJEAEkDpRQOeFwA0UP/14lZ46QTAk3LpZG3hVCaMZa
P5xvGECGpInvvgT/A3frHLrAsJ65Aem9vjLpCb43Q7SX3PRSEtVoxJu1ay7EFiwk
aLqk9VX/871XTyvpaM8ArLYjzi0Q6KZFSHyxlysoAZPFUImmjIYPzrzd5lVo6tg0
zPyBUvWmyqK2u8gYZtst+3FL2yqBLqzgPg29Xf7+gX9ROtyGbynHWvh1lIgvH0GI
0vI4GqmKVy7UD3yskNEuM5Ra6iGoYwlg7n+BHCiQ7g1dZ7JwH+nP2KOEUsrlLa40
pQS0T03RnfvZZVjhM3DP0lUqZltKcGiZtrLEOe3Nw99hc8w0IDlZOGTG1sqMvkpn
JtSih7d+sjk12JI4TR9Kv0UYcaHwKI4AoWpMGkr7zzjJFgPDcalsEooG9ti32y4w
VioH4DJ6E76+TgakIWbXEtunPOf1IxqPPEql42Z/Ubq+vB27Cwga23bzZ0ziBh9k
BxszTLMTJHvlVOe4gPHdl2DYnmgkDQXevdNgMvj+xmEh7+Jl4w9xexJJWMNQ/Ffo
9gGI9GUBUgEprzjC8tkQxrMaUcrvKRy0Khybd8wv2vpwK9wfrJ4nhXS0Pohbq+m1
Oib2B4K51MC7C+fuUWn8JES88/3zuqUIgNsNRbcUMuBrDot6rwi8GSUmvuur3oGm
WRSUDmm6heJADifDBwep
=UG0E
-END PGP SIGNATURE-

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

[Rich Freeman]

On Thu, Feb 11, 2016 at 7:12 PM, Daniel Campbell  wrote:
>
> No, lazy USE in this discussion is akin to installing, say, Steam.
> That requires a lot of packages that must be rebuilt with abi_x86_32.
> In such a situation, if there was something like USE="~abi_x86_32"
> (the ~ is just a symbol, it wouldn't have to be that exact symbol),
> then packages that need that USE flag would automatically use it, and
> those that don't need it wouldn't be built with it.

Actually, I was proposing that you'd only need USE="~abi_x86_32" if
you set USE="-abi_x86_32" someplace else.  Adding a ~ would just
remove any previous settings - it wouldn't cause a use flag to be
turned on or off.  You could have a flag like that even without lazy
use flag support - it could be used to cause a single package to
revert to its default use flags.  I'm not really sure if it is a
terribly useful feature at all.

In my proposal you wouldn't need to do anything at all on a default
profile to have USE="abi_x86_32" enabled for packages that had that
use dependency in some other package.  Just running emerge steam would
cause rebuilds on anything that didn't already have 32-bit support
which required it.  You'd only need to mess with your flags if you had
explicitly set USE="-abi_x86_32" - which makes sense since you've now
given portage two contradicting directives.

Just as you don't need to do anything special to have "emerge
chromium" pull in libX11, you wouldn't need to do anything special to
have "emerge chromium" cause hwids to rebuild with USE=usb if it isn't
already built that way, unless you had explicitly set USE=-usb.

And of course this should be something that can be turned off, and
users can always run -pv to see what portage is going to do.

-- 
Rich

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/11/2016 04:01 PM, William Hubbs wrote:
> I'm just picking a random message in the thread to reply to.
> 
> In the past, we had a feature, I think it was called "auto use",
> that would automatically turn on a use flag if the package that was
> needed to support it was installed.
> 
> As an example, if we still had this, python_targets_2_7 would be 
> automatically turned on if dev-lang/python-2.7 was installed.
> 
> Is this along the lines of what we are talking about?
> 
> William
> 

No, lazy USE in this discussion is akin to installing, say, Steam.
That requires a lot of packages that must be rebuilt with abi_x86_32.
In such a situation, if there was something like USE="~abi_x86_32"
(the ~ is just a symbol, it wouldn't have to be that exact symbol),
then packages that need that USE flag would automatically use it, and
those that don't need it wouldn't be built with it.

It's kind of a "I'll allow this USE flag, but only if you need it"
instead of what we currently have, which is a hard YES or NO. The
in-between case (not clarifying USE flags at all) works fine for
packages but not necessarily for USE flags. Installing something like
Steam, wine, or Skype requires a huge swath of abi_x86_32 flags.

I and others get around this by partitioning these flags to files, but
should something in dependencies change, we'll still be building those
packages in 32-bit unnecessarily.

So it's closer to what we do for dependency resolution on packages,
just applied to USE flags.

(hopefully I explained well enough)

- -- 
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

iQIcBAEBCAAGBQJWvSNnAAoJEAEkDpRQOeFwVd4P/2h2D31S2jOiafs9PM0In8VD
PasOphNcKIQp+SNmN5BRQNieKXKRpSzkQSvb1Sk3UUOsR+36jN23GtvLeYvpEJsg
fsjsrZrBs9Wvv/eMK2+OAU1VCXDx4Mbc5uSCc0JM+nNhx2IR9jvfGefto3WD0pC5
Bjg5mP+yB/MZ+IXUaHKVmTtiGo0PM3NRPUOlaOi0icMw5OUFlvY9eQo2z0dEaNrq
SDTsm19adaxsygZPiog101KHGZ1NgoYWZcA+sIR97ZU0tIQPBd9RKVcUe7Q/4YOu
DH5mSWDyBwsdGY6wVfoNkrWhpL7ZvRqux5C3bicOtep+dvbog5cBAljQOxB39to4
3g/ufouooBk1GIzMFdo3JI3i9DB0rwCY2PLJsMGRQxYdQZo3K75LQDwG78gHOEMD
+YOiC/T0zOx6NZ3L4Nfw0ntD0/T0NxiM9IOg2E1hK01W8ehpwCvhriVKR9SyReW4
6pkzMzgJNBUG6T35+hwUbgb1AsM/Pk7Ye21+DWO4ed/7EFj8QlXe0Yk9At9RMTe1
8mdV7oQSvE3BaYhFmsUOgiiiMFqx7IyVmiBUvBVpnmDSxk7NRPSSVl5sP900yDlx
eHdy9uazaWgnWYyZU1zKpIAD3wn5Qo3BbdDMj4VC+IsLAvvovSnkOFwEIAGgmrN7
vCz3wmcDozbSh0vXuUWk
=X+4h
-END PGP SIGNATURE-

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

[William Hubbs]

I'm just picking a random message in the thread to reply to.

In the past, we had a feature, I think it was called "auto use", that
would automatically turn on a use flag if the package that was needed to
support it was installed.

As an example, if we still had this, python_targets_2_7 would be
automatically turned on if dev-lang/python-2.7 was installed.

Is this along the lines of what we are talking about?

William



signature.asc
Description: Digital signature

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/11/2016 04:59 AM, Rich Freeman wrote:
> On Wed, Feb 10, 2016 at 10:46 PM, Daniel Campbell  
> wrote:
>> 
>> On 02/10/2016 06:51 PM, Rich Freeman wrote:
>>> 
>>> Ditto for stuff like 32-bit support for half the libraries on 
>>> your system when you're using something like wine.  Just don't 
>>> set the flag except explicitly if you actually need it 
>>> somewhere, and it will get pulled in where it is needed, and
>>> go away when it is no longer needed.
>>> 
>> 
>> re multilib, under what configuration does abi_x86_32 get set on 
>> its own? With a blank ABI_X86 variable in make.conf? Every
>> 32-bit package I've ever pulled in has needed that flag set, and
>> I've had to manually set it until blockers are resolved. I've not
>> set -abi_x86_32 globally or anything like that.
> 
> We're talking about a proposed portage feature which hasn't been 
> written yet.  None of the behavior described in this thread happens
> today.  Right now all those abi_x86_32 flags are set explicitly,
> which is why my package.use file is about 10x larger than it used
> to be. I'm contemplating splitting out the 32-bit stuff into a
> separate file and just nuking it every 6-months and allowing
> portage to re-create it to try to keep it somewhat manageable.
> 
> And that is the inspiration for this.  The current design mixes 
> true user preferences with stuff added by auto-unmask needed just 
> to fulfill dependencies.  Users should be easily able to
> prioritize the one above the other.  Indeed, maybe I have a few
> 32-bit library preferences which are explicit and now if I go to
> nuke then every six months I have to keep track of which ones are
> which.
> 
> With the proposed lazy use flags then for the most part 32-bit 
> support would be automagic for most users.
> 

Okay, I wasn't sure if you were talking what's already here or the
main topic. Thanks for clarifying. I think lazy USE would be a big
plus for multilib users.

- -- 
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

iQIcBAEBCAAGBQJWvR5kAAoJEAEkDpRQOeFwfCoP/2bdwfRQOSG/OZ0HtcTZCGzV
UKM8i3Z1kPL7QVgDA24kDDvPwyPDsGIm9x0/fe/UeDlQ3tkSqhQvbBukNXEW0gaJ
qMNQBPmnGfGOhr0o0VylvMGZCq4IKGW8hQdBtjA/QTCSKiASAM1j+IjlvBSk1n6V
G+eqoGdY50xF8C8tix1ozmA1ZHP49sU1nE1Dnzg+AA3AESgfrxJ2ys9ccB7vwIny
dWD5HXzTNjhc4OkiqWSBfO9CESEPe/vKbk5la7HxdVB/auKm52A/O81Bs+8YXHlL
IB3k81lpEY08O7lfVzfJqj0uN+7yF6v6pRVwDdnDGbJQCbun5hfmQBlmGYHEEDMf
z2SI6eIPkYWlonEgmBOkvu1fZP7gdXs9gPHnsGd3QxdjBiqOyb3AckqcxQDiczKf
1xDs8isXenEtSV4MTjO/JwyJT1sgORn3y+iFvUMDdOtjWFAs4xHMZRiqcgQ9hn+3
Q7PgB1VLw85THQBFtE2s4FtM9H2I9oRPVDM10OEXFiIVtH2Kkh9LWHr/CdkpGt9I
MEDt0HH9m6so2JW407BX8nhT6eL8QZCOEzm7zjfMeFNFbbctRtIEhj3DiSPvYIq+
OyRJ7f3zqygwV+wH09y9fmCJ/bJzrIsRARsAw9V/lW4MLLRQ3IfqWfsQG/BSYFWL
CLLROLSNbTQR16QxUiJq
=/IrH
-END PGP SIGNATURE-

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

[Róbert Čerňanský]

On Thu, 11 Feb 2016 07:55:52 -0500
Rich Freeman  wrote:

> On Wed, Feb 10, 2016 at 11:57 PM, Kent Fredric
>  wrote:
> > On 11 February 2016 at 15:51, Rich Freeman  wrote:
> >> In this case you just wouldn't enable python 2.7 support, but you
> >> wouldn't disable it either.  Portage would just pull it in where
> >> it is needed.
[...] 
> Perhaps it might make sense to introduce a new ~foo setting which
> undoes a +/-foo in make.conf but doesn't set it either + or - in
> package.use, allowing the setting to revert to the default behavior.
> That would actually be useful independent of lazy use flags, but would
> be more useful with lazy use flags.

Having also ~foo syntax (together with omiting use flags) seems to me
as best option now actually.  It would support also Kent's use case I
think.

Taking that use case as an example - if I would want to get rid of
python-2.7 as soon as possible I'd set -python_targets_python2_7 in
make.conf.  For those packages which portage screams that needs
python_targets_python2_7 I'd set ~python_targets_python2_7 in
package.use.

In time when last of those packages stops hard-requiring
python_targets_python2_7 the python-2.7 package itself would be
depcleaned and I could remove '~' entries from package.use.

Nice and clean :-) .


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

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

[Kent Fredric]

On 12 February 2016 at 03:48, M. J. Everitt  wrote:
> Well, that's obvious 


Makes more sense if you read this:

> Any file in this directory, directories of other profiles or top-level 
> "profiles" directory that begins with "package." or "use."
> can  be  more  than just a flat file.  If it is a directory, then all the 
> files in that directory will be sorted in ascending
> alphabetical order by  file name and summed together as if it were a single 
> file.

And so if that's considered a "Single logical file" and the normal
behaviour is "Append to the single file", then by proxy, the logical
place to append in a multi-file scenario is the "last" one.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[M. J. Everitt]

On 11/02/16 14:46, Kent Fredric wrote:
> On 12 February 2016 at 03:43, M. J. Everitt  wrote:
>> auto-unmask has a very inconsistent, unstable way of
>> working with a package.use folder not file ...
>
> auto-unmask consistently adds items to the file with the highest
> dictionary sort.
>
> So if you name all the files with numerical prefixes, 00 .. 99, "99"
> is where auto-unmask will write to.
>
Well, that's obvious 

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

[Kent Fredric]

On 12 February 2016 at 03:43, M. J. Everitt  wrote:
> auto-unmask has a very inconsistent, unstable way of
> working with a package.use folder not file ...


auto-unmask consistently adds items to the file with the highest
dictionary sort.

So if you name all the files with numerical prefixes, 00 .. 99, "99"
is where auto-unmask will write to.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[M. J. Everitt]

On 11/02/16 14:32, Kent Fredric wrote:
>> and has no support of per-category files (that I know of).
> # /etc/portage/package.use/dev-qt
> dev-qt/*  qt3support
>
> ^ Legal, works
>
>
Portage does, auto-unmask has a very inconsistent, unstable way of
working with a package.use folder not file ...

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

[Kent Fredric]

On 12 February 2016 at 03:19, M. J. Everitt  wrote:
> I would avoid complicating the USE flag system .. it's straightforward
> as it is, and has already been 'tweaked' by the auto-unmask feature,
> leading to large package.use files and has no support of per-category
> files (that I know of).


Auto-unmask is creating a problem here though, it enables useflags,
and has no way to disable them again when their utility has long
passed.

As per

> and has no support of per-category files (that I know of).

# /etc/portage/package.use/dev-qt
dev-qt/*  qt3support

^ Legal, works




-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Kent Fredric]

On 12 February 2016 at 02:54, NP-Hardass  wrote:
> Just a slightly OT side note...

Quite, these are the *sorts* of things I've been mulling over for a
bit without coming to a concrete implementation idea.

> I split mine off into a separate file (using a directory for package.use
> ).
> I proposed a feature a while back,
> https://bugs.gentoo.org/show_bug.cgi?id=534548, where all use flags
> are stored in /etc/portage/package.use/${USE_EXPAND}  to help with
> management.

My experience so far has been similar, in that clustering settings
based on the setting tends to be a good primary classifier.

Though I maintain 2 different layout structures depending on task:

Scheme 1 I use for package.use and keywords and stuff:

package.use/01-${cat}# contains use settings for all packages in ${cat}
package.use/90-${task}   # contains all settings for use flags that
achieve a single "task" ( like I have an entire file just for the
legacy abi_x86_32 support )
package.use/99-autounmask # because auto-unmask writes to the last
file alphabetically, so garbage goes in here if I ever make the
mistake of using autounmask-write again

Scheme 2 I use for package.env

package.env/${task}/${pn}

Where "$task" is as above, but "${pn}" is the program-in-world-I-want,
and the file contains settings that achieve "task" for its
dependencies.

This is me trying to approximate a "Lazy" graph, as each entry named
"${pn}" says:

<=cat/pn-$version py2.7

# deps
   cat/pn py2.7
   cat/pn py2.7

That way, every time an update to ${pn} happens where it still needs
the old python, it cries about it, but in the future it will be
trivial to check "packages I have installed" vs "lazy rule files I
have" and see when the condition is no longer required, and I can
simply reap the whole file. ( This is kinda hell because of all the
overlapping dependencies, but its better than nothing )


> Yet another feature similar to lazy eval of use flags is another bug I
> created a while back, recommended and conditional use flags
> https://bugs.gentoo.org/show_bug.cgi?id=539124.

recommended I wanted too, but I figured it would be easy enough to
bodge around it with:

IUSE="minimal suggested feature"
DEPEND="!minimal? ( feature_dep )
 feature? ( feature_dep )
"

Or something like that. ( using the word "minimal" as a stand in for
"don't pull recommended stuff" because that's already a global
useflag, and under the assumption that the words "recommended" implies
"Installed by default" )

But in the feature as stated, there's a bit of a gap conceptually,
because sometimes upstream produce a set of dependencies with no
description other than "these are all recommended deps and you should
have all of them, unless you're working in very constrained
circumstances and you know what you're doing, and things may break in
certain code paths if you don't install them", and "RECOMMENDED_USE"
here doesn't exactly cover that featureset. You'd still need an
explicit "minimal" for that.

Conditional I kinda thought about and decided "naah, too complex,
you'll blow any resolver up with that  stuff" .

Though we may be wanting different things entirely in "recommended
useflags", because I'm riffing more on "recommended dependencies"
which may incidentally be "dependencies required by this package if a
certain package is to use it", and the only way to communicate that
between packages at present is with  "cat-egory/pakc-1.2[-minimal]"

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[M. J. Everitt]

On 11/02/16 12:55, Rich Freeman wrote:
> On Wed, Feb 10, 2016 at 11:57 PM, Kent Fredric  wrote:
>> On 11 February 2016 at 15:51, Rich Freeman  wrote:
>>> In this case you just wouldn't enable python 2.7 support, but you
>>> wouldn't disable it either.  Portage would just pull it in where it is
>>> needed.
>> But you still need a mechanism in place if you *dont* want that to happen.
>> ...
>>> Unless of course you're suggesting "USE=-python_targets_python2_7"
>> would not be "auto-enableable"
> That is correct.
>
>> But then you're *still* requiring a tri-state USE.
> Sure - it would be the same as how package-versions work today.
>
> Stick it in world, and you're pulling it in.
>
> Stick in in mask, and you're keeping it out.
>
> Don't do anything, and portage does what it thinks is best, guided by
> profiles/etc.
>
>> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
> This is the only thing that would change.  In all the other scenarios
> you described the behavior would be the same as today.  If you set
> USE=-foo then you'll get the same errors you get today.
>
> Now, auto-unmask could still propose sticking USE=+foo in your
> package.use if you have USE=-foo in your make.conf, which is already
> the behavior today.  If you've made any explicit USE setting in your
> configuration, portage would never ignore it, but only suggest that
> you change it.
>
> Perhaps it might make sense to introduce a new ~foo setting which
> undoes a +/-foo in make.conf but doesn't set it either + or - in
> package.use, allowing the setting to revert to the default behavior.
> That would actually be useful independent of lazy use flags, but would
> be more useful with lazy use flags.
>
>> Mentally keeping track of this accounting magic would be complicating 
>> matters.
>>
> I think you're overthinking this.  It is completely analogous as to
> what portage already does with package-versions.  I don't have libjpeg
> in my world file, and yet portage installs it, and I don't think about
> it either way.  If I wanted to pin a specific version of it or mask it
> I could, but of course the preference of most users is to micromanage
> as little as possible.
>
> Basically lazy use flags is intended for users to minimize the size of
> their package.use files, just as they already minimize the size of
> their @world and package.mask files today.
>
I would avoid complicating the USE flag system .. it's straightforward
as it is, and has already been 'tweaked' by the auto-unmask feature,
leading to large package.use files and has no support of per-category
files (that I know of).

I would propose the introduction of a 'LUSE' flag (lazy-use or
lightweight-use) which serves as a fall-back if the main USE system
"fails" - ok this requires duplication of the existing checking system
(and hence integration with portage) but it would allow you to set USE
flags per system at install .. and you could 'tweak' LUSE flags to suit
package implementations instead.

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/11/2016 07:59 AM, Rich Freeman wrote:
> On Wed, Feb 10, 2016 at 10:46 PM, Daniel Campbell 
> wrote:
>> 
>> On 02/10/2016 06:51 PM, Rich Freeman wrote:
>>> 
>>> Ditto for stuff like 32-bit support for half the libraries on
>>> your system when you're using something like wine.  Just don't
>>> set the flag except explicitly if you actually need it
>>> somewhere, and it will get pulled in where it is needed, and go
>>> away when it is no longer needed.
>>> 
>> 
>> re multilib, under what configuration does abi_x86_32 get set on
>> its own? With a blank ABI_X86 variable in make.conf? Every 32-bit
>> package I've ever pulled in has needed that flag set, and I've
>> had to manually set it until blockers are resolved. I've not set
>> -abi_x86_32 globally or anything like that.
> 
> We're talking about a proposed portage feature which hasn't been 
> written yet.  None of the behavior described in this thread
> happens today.  Right now all those abi_x86_32 flags are set
> explicitly, which is why my package.use file is about 10x larger
> than it used to be. I'm contemplating splitting out the 32-bit
> stuff into a separate file and just nuking it every 6-months and
> allowing portage to re-create it to try to keep it somewhat
> manageable.
> 
> And that is the inspiration for this.  The current design mixes
> true user preferences with stuff added by auto-unmask needed just
> to fulfill dependencies.  Users should be easily able to prioritize
> the one above the other.  Indeed, maybe I have a few 32-bit
> library preferences which are explicit and now if I go to nuke then
> every six months I have to keep track of which ones are which.
> 
> With the proposed lazy use flags then for the most part 32-bit
> support would be automagic for most users.
> 

Just a slightly OT side note...
I split mine off into a separate file (using a directory for package.use
).
I proposed a feature a while back,
https://bugs.gentoo.org/show_bug.cgi?id=534548, where all use flags
are stored in /etc/portage/package.use/${USE_EXPAND}  to help with
management.
Yet another feature similar to lazy eval of use flags is another bug I
created a while back, recommended and conditional use flags
https://bugs.gentoo.org/show_bug.cgi?id=539124.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWvJKXAAoJEBzZQR2yrxj7AA0QAJitT6khf7R9ShDTMOuv7BWG
H6APtpLWQCOVmsHo/5muDE/YTytIe+d7OIf4lvjXOegA9NcskZd3PFCuE0ixORhE
bo6q2eO+sgEgJA4pkWUoxbovm7esM6AHnsnKb63EymfwJz2GReTkgkgZiG4c4o3y
60twObyNzDmfsKoVGZWUL5Z4kk3WrgRq78Dtg50fsOlGgAKw27LObf2OIzMqFcWt
w0zHLu48dffae3vQ8Y1RpG/hGP/GFw/Czb/9XhU+BVvZrwtLjH/4hmEWRwUve+g6
6tpxUuiOi3VByxj4OklRxyxhlZypA2rmGu4WS3dzsw87tmJ5nZ9ASRsO5uKQ61wP
YskaGYyVn8v/26zL1Mw+XBsw3OFU1O5tHhaQazVW2fdv0vhnOOS+t4HUH2DKM2xV
Yo4OAX0sWHKpCZwiRE6Wi4JUHLHxF2+wlHx9+XKR9q5M1ErmMyG+ovPXBFhiZ2mH
6kCkh59HiL67Z8wplM/51rQA6dj2cgPZ9MosNCIRX+szpjsJN6sLxuGykIJAUVUU
0MVS/N+PgwMSSXtAZIE4Kd28qqoqYbw+qFQ3hqxBp9D8WzQf4c6HysAGDI7PAJeM
hKbmfE6qnn27py1Vm+FvL0rGpfsMRdSmcbT3QGh/XCgKLl/VE64ALwYNGgaeJ0iJ
WHRYXZf2dwABaCx248SA
=kznA
-END PGP SIGNATURE-

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

[Rich Freeman]

On Wed, Feb 10, 2016 at 10:46 PM, Daniel Campbell  wrote:
>
> On 02/10/2016 06:51 PM, Rich Freeman wrote:
>>
>> Ditto for stuff like 32-bit support for half the libraries on your
>> system when you're using something like wine.  Just don't set the
>> flag except explicitly if you actually need it somewhere, and it
>> will get pulled in where it is needed, and go away when it is no
>> longer needed.
>>
>
> re multilib, under what configuration does abi_x86_32 get set on its
> own? With a blank ABI_X86 variable in make.conf? Every 32-bit package
> I've ever pulled in has needed that flag set, and I've had to manually
> set it until blockers are resolved. I've not set -abi_x86_32 globally
> or anything like that.

We're talking about a proposed portage feature which hasn't been
written yet.  None of the behavior described in this thread happens
today.  Right now all those abi_x86_32 flags are set explicitly, which
is why my package.use file is about 10x larger than it used to be.
I'm contemplating splitting out the 32-bit stuff into a separate file
and just nuking it every 6-months and allowing portage to re-create it
to try to keep it somewhat manageable.

And that is the inspiration for this.  The current design mixes true
user preferences with stuff added by auto-unmask needed just to
fulfill dependencies.  Users should be easily able to prioritize the
one above the other.  Indeed, maybe I have a few 32-bit library
preferences which are explicit and now if I go to nuke then every six
months I have to keep track of which ones are which.

With the proposed lazy use flags then for the most part 32-bit support
would be automagic for most users.

-- 
Rich

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

[Rich Freeman]

On Wed, Feb 10, 2016 at 11:57 PM, Kent Fredric  wrote:
> On 11 February 2016 at 15:51, Rich Freeman  wrote:
>> In this case you just wouldn't enable python 2.7 support, but you
>> wouldn't disable it either.  Portage would just pull it in where it is
>> needed.
>
> But you still need a mechanism in place if you *dont* want that to happen.
>...
>> Unless of course you're suggesting "USE=-python_targets_python2_7"
> would not be "auto-enableable"

That is correct.

>
> But then you're *still* requiring a tri-state USE.

Sure - it would be the same as how package-versions work today.

Stick it in world, and you're pulling it in.

Stick in in mask, and you're keeping it out.

Don't do anything, and portage does what it thinks is best, guided by
profiles/etc.

> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required

This is the only thing that would change.  In all the other scenarios
you described the behavior would be the same as today.  If you set
USE=-foo then you'll get the same errors you get today.

Now, auto-unmask could still propose sticking USE=+foo in your
package.use if you have USE=-foo in your make.conf, which is already
the behavior today.  If you've made any explicit USE setting in your
configuration, portage would never ignore it, but only suggest that
you change it.

Perhaps it might make sense to introduce a new ~foo setting which
undoes a +/-foo in make.conf but doesn't set it either + or - in
package.use, allowing the setting to revert to the default behavior.
That would actually be useful independent of lazy use flags, but would
be more useful with lazy use flags.

>
> Mentally keeping track of this accounting magic would be complicating matters.
>

I think you're overthinking this.  It is completely analogous as to
what portage already does with package-versions.  I don't have libjpeg
in my world file, and yet portage installs it, and I don't think about
it either way.  If I wanted to pin a specific version of it or mask it
I could, but of course the preference of most users is to micromanage
as little as possible.

Basically lazy use flags is intended for users to minimize the size of
their package.use files, just as they already minimize the size of
their @world and package.mask files today.

-- 
Rich

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

[Raymond Jennings]

Yeah the "soft" thing was meant as "do this unless something breaks, then
do it otherwise"

On Wed, Feb 10, 2016 at 8:57 PM, Kent Fredric  wrote:

> On 11 February 2016 at 15:51, Rich Freeman  wrote:
> > In this case you just wouldn't enable python 2.7 support, but you
> > wouldn't disable it either.  Portage would just pull it in where it is
> > needed.
>
>
> But you still need a mechanism in place if you *dont* want that to happen.
>
> I might choose to forbid python2.7 support, and portage really
> shouldn't "auto enable" python 2.7 support if I've explicitly
> indicated I don't want python 2.7 support.
>
> Unless of course you're suggesting "USE=-python_targets_python2_7"
> would not be "auto-enableable"
>
> But then you're *still* requiring a tri-state USE.
>
> USE="-foo" + IUSE="+foo" => "-foo"  => autouse enables foo if required
> USE=""  + IUSE="+foo" => "foo"=> standard EFFECTIVE_USE="foo"
> USE="foo" + IUSE = "+foo" => "foo" => standard EFFECTIVE_USE="foo"
> USE="-foo" + IUSE="foo" => "-foo"  => autouse enables foo if required
> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
> USE="foo"  + IUSE="foo" => "foo"   => standard EFFECTIVE_USE="foo"
>
>
> So the logic composing USE + IUSE has to change in generating the
> effective USE set so that USE + IUSE can emit a 3rd and 4th state.
>
> USE="-foo" + IUSE="+foo" => "-foo!!"  => autouse fails if foo is required
> USE=""  + IUSE="+foo" => "foo"=>  standard
> EFFECTIVE_USE="foo", auto-unuses foo if blocked by a dep
> USE="foo" + IUSE = "+foo" => "foo!!" => standard EFFECTIVE_USE="foo",
> fails if foo is "blocked" by a dep
> USE="-foo" + IUSE="foo" => "-foo!!"  => autouse fails if foo is required
> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
> USE="foo"  + IUSE="foo" => "foo!!"   => standard EFFECTIVE_USE="foo",
> fails if "foo" is blocked by a dep.
>
>
> Mentally keeping track of this accounting magic would be complicating
> matters.
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>
>

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

[Kent Fredric]

On 11 February 2016 at 15:51, Rich Freeman  wrote:
> In this case you just wouldn't enable python 2.7 support, but you
> wouldn't disable it either.  Portage would just pull it in where it is
> needed.


But you still need a mechanism in place if you *dont* want that to happen.

I might choose to forbid python2.7 support, and portage really
shouldn't "auto enable" python 2.7 support if I've explicitly
indicated I don't want python 2.7 support.

Unless of course you're suggesting "USE=-python_targets_python2_7"
would not be "auto-enableable"

But then you're *still* requiring a tri-state USE.

USE="-foo" + IUSE="+foo" => "-foo"  => autouse enables foo if required
USE=""  + IUSE="+foo" => "foo"=> standard EFFECTIVE_USE="foo"
USE="foo" + IUSE = "+foo" => "foo" => standard EFFECTIVE_USE="foo"
USE="-foo" + IUSE="foo" => "-foo"  => autouse enables foo if required
USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
USE="foo"  + IUSE="foo" => "foo"   => standard EFFECTIVE_USE="foo"


So the logic composing USE + IUSE has to change in generating the
effective USE set so that USE + IUSE can emit a 3rd and 4th state.

USE="-foo" + IUSE="+foo" => "-foo!!"  => autouse fails if foo is required
USE=""  + IUSE="+foo" => "foo"=>  standard
EFFECTIVE_USE="foo", auto-unuses foo if blocked by a dep
USE="foo" + IUSE = "+foo" => "foo!!" => standard EFFECTIVE_USE="foo",
fails if foo is "blocked" by a dep
USE="-foo" + IUSE="foo" => "-foo!!"  => autouse fails if foo is required
USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
USE="foo"  + IUSE="foo" => "foo!!"   => standard EFFECTIVE_USE="foo",
fails if "foo" is blocked by a dep.


Mentally keeping track of this accounting magic would be complicating matters.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/10/2016 06:51 PM, Rich Freeman wrote:
> On Wed, Feb 10, 2016 at 9:18 PM, Kent Fredric
>  wrote:
>> 
>> Hence, this requires me to lie to portage about what my
>> preferences are to get it to play ball, constantly going "Hey
>> portage, I actually want python 2.7 shit, please install it".
>> 
> 
> In this case you just wouldn't enable python 2.7 support, but you 
> wouldn't disable it either.  Portage would just pull it in where it
> is needed.
> 
> Ditto for stuff like 32-bit support for half the libraries on your 
> system when you're using something like wine.  Just don't set the
> flag except explicitly if you actually need it somewhere, and it
> will get pulled in where it is needed, and go away when it is no
> longer needed.
> 
> The idea is that USE flags would behave the same way as 
> package-versions.  If portage needs it then it gets installed, and 
> when it isn't needed it gets depcleaned.
> 

re multilib, under what configuration does abi_x86_32 get set on its
own? With a blank ABI_X86 variable in make.conf? Every 32-bit package
I've ever pulled in has needed that flag set, and I've had to manually
set it until blockers are resolved. I've not set -abi_x86_32 globally
or anything like that.

- -- 
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

iQIcBAEBCAAGBQJWvAQBAAoJEAEkDpRQOeFw+xsP/2SZXSXgFFecQ4NTyrKzb6kf
Xh70j6zTjnp3D/AMJi8+s4VU7q78KGWEWxofg6kEqENe2bPlMLapeVkzvrI42VZ4
KdIdumh/sbu4ZwA3xEQHoCHRRfE0FQZPwlK16qt0LeiLsIbprlETzRE31d/D5ui3
Atgg9s6ZUWLpZYGkf3afjZpqLJyLijBEu+cUun7hd/zpNu6aKEDd4I5bKjrps/26
2rwW5zRy2qPr1U0nBS8xgQA4QwGmmg3Jtbtk5KeWjOJ3dEvazSjxHOYNv95bbNBj
N4leSXdKh33qr3uAWmDfKvQGwS4aNcN/8+7nQ0GwlJda4tT94YO4VvlhO1qe0ip7
dW9NNRlOZ420vFWR7S2dxyeSnyg9+zpSbx4Z3UNYN30Cd/AG17+ON8uRWJmbpRdZ
UfU86CdKW8eFHeDn96kGPlJg6Hm/BrnFB+PZCws4v+/nF7POJ4OptQQQ6gFmhf6D
M9YciobV4i0bfDuwg7SAQpiyJ1hShe0z4qLmwGpcF/D8IFpv7EjcOxW0syMvlZzq
4PQzlKshnl0YCDhMfCNRsg9ru6FTrWyRlBqaJMeXYez38r91CgRRjKoY3hoqiOxM
bkKtWn/eVzE2W+qjz5sP3cSaJzPwJmj3ldiiyVCbYqYFmW6jgIPnWJt6a0Tvr4TN
DPnup09W3Kx5W9qmSz+n
=GNMb
-END PGP SIGNATURE-

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

[Rich Freeman]

On Wed, Feb 10, 2016 at 9:18 PM, Kent Fredric  wrote:
>
> Hence, this requires me to lie to portage about what my preferences
> are to get it to play ball, constantly going "Hey portage, I actually
> want python 2.7 shit, please install it".
>

In this case you just wouldn't enable python 2.7 support, but you
wouldn't disable it either.  Portage would just pull it in where it is
needed.

Ditto for stuff like 32-bit support for half the libraries on your
system when you're using something like wine.  Just don't set the flag
except explicitly if you actually need it somewhere, and it will get
pulled in where it is needed, and go away when it is no longer needed.

The idea is that USE flags would behave the same way as
package-versions.  If portage needs it then it gets installed, and
when it isn't needed it gets depcleaned.

-- 
Rich

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

[Kent Fredric]

On 11 February 2016 at 13:42, Rich Freeman  wrote:
>> soft disable = Disable, unless it would break a dependency
>
> I don't really see why these are needed.  Just do what we are already
> doing - use the settings in the profile and package defaults.


And soft-disable would be for things where

IUSE="+flag"

Where you didn't like "flag", but application of < USE="-flag" > can
conditionally cause breakages due to other packages doing
DEPEND="package[flag]"

But would otherwise be identical to "Soft-enable"

Just his descriptions are strange.

I think a better description for the set of possible settings are:

enable:  USE="foo"
permit:  treat as USE="" by default, so IUSE="+foo" still defaults to
"on", but turn USE="foo" on if dependency conditions require it.
discourage: treat as USE="-foo" by default, so IUSE="+foo" gets vetoed
to "off", but can be still enabled by dependency conditions
forbid: USE="-foo"



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Kent Fredric]

On 11 February 2016 at 13:42, Rich Freeman  wrote:
> I'm not sure why I'd want to set a preference and then just have the
> system ignore it without telling me.  If I tell it I want a flag
> on/off then yell at me if it is a problem.


I "prefer" not to pull in python packages and build python support for
versions of python I'm trying to prune from my tree.

But my "preference" in regard is not a useful preference, because
portage doesn't care about my preference when another package states
it will fail unless I do otherwise.

Hence, this requires me to lie to portage about what my preferences
are to get it to play ball, constantly going "Hey portage, I actually
want python 2.7 shit, please install it".

And after that point, it thinks I want python 2.7 shit, even if
nothing else needs it, because I've now said "I need it" as a side
effect of some package forcing my hand.

At least this way, instead of saying "I need it", I'd be saying "I
will permit this", but my preference is to the contrary, and "Please
respect my contrary preference as soon as it becomes viable to do so"

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Rich Freeman]

On Wed, Feb 10, 2016 at 7:18 PM, Raymond Jennings  wrote:
>
> soft enable = Enable, unless it would break dependency
> soft disable = Disable, unless it would break a dependency

I don't really see why these are needed.  Just do what we are already
doing - use the settings in the profile and package defaults.

I'm not sure why I'd want to set a preference and then just have the
system ignore it without telling me.  If I tell it I want a flag
on/off then yell at me if it is a problem.

However, what I don't want to do is have a 5000 line package.use
because of a bunch of settings I really don't care about, which then
cause problems down the road...

--
Rich

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

[Raymond Jennings]

I suppose we could consider it as a hard vs soft configuration?

hard enable = Enable no matter what, and cause an error
soft enable = Enable, unless it would break dependency
soft disable = Disable, unless it would break a dependency
hard disable = Disable no matter what, and cause an error

On Wed, Feb 10, 2016 at 12:00 PM, Róbert Čerňanský 
wrote:

> On Wed, 10 Feb 2016 15:23:27 +1300
> Kent Fredric  wrote:
>
> > >> I'd personally rather the list of "automatically turn this on if
> > >> required" be something I had the power to restrict than have a
> > >> blanket "autodostuff", because in the event some USE can't be
>
> Although I prefer non-explicit auto/lazy use flags, the explicit
> approach is also perfectly fine (especially when compared to current
> situation).  In the end I would most certainly be able to specify all
> use flags as lazy and thus have effectively the same behaviour as with
> non-explicit approach.
>
> > So in comparison:
> >
> > /etc/portage/package.use  is essentially "the world file but for
> > useflags"
> >
> > And we have no analogue of
> >
> > /etc/porage/package.unmask  or /etc/portage/package.keywords that
> > applies to useflags.
>
> I find /etc/portage/package.use (or make.conf) analogous to world AND
> mask files.  For packages world + mask files give you possibility to
> specify which packages you:
>
> - want (listed in world file)
> - don't want (listed in a mask file)
> - not care (not listed in any of them)
>
> (Assuming non-explicit approach) similarly for use flags, package.use
> or make.conf gives you possibility to specify which use flags you:
>
> - want (listed in package.use or make.conf)
> - don't want (listed with '-' in package.use or make.conf)
> - not care (not listed in any of them)
>
> The advantage of explicit approach could be that even if a use flag is
> enabled or disabled globally, it would still be possible to make it
> lazy/automatic for specific packages.
>
> > I can see how some people might want an analogue of "just install
> > dependencies if they're needed regardless if I said I need them" that
> > applies to useflags, but you'd probably want a "don't install this
> > even if it appeared to be needed" companion tool that behaves akin to
> > /etc/portage/package.mask
>
> This would be package.use or make.conf.
>
>
> --
> Róbert Čerňanský
> E-mail: ope...@tightmail.com
> Jabber: h...@jabber.sk
>
>

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

[Róbert Čerňanský]

On Wed, 10 Feb 2016 15:23:27 +1300
Kent Fredric  wrote:

> >> I'd personally rather the list of "automatically turn this on if
> >> required" be something I had the power to restrict than have a
> >> blanket "autodostuff", because in the event some USE can't be

Although I prefer non-explicit auto/lazy use flags, the explicit
approach is also perfectly fine (especially when compared to current
situation).  In the end I would most certainly be able to specify all
use flags as lazy and thus have effectively the same behaviour as with
non-explicit approach.

> So in comparison:
> 
> /etc/portage/package.use  is essentially "the world file but for
> useflags"
> 
> And we have no analogue of
> 
> /etc/porage/package.unmask  or /etc/portage/package.keywords that
> applies to useflags.

I find /etc/portage/package.use (or make.conf) analogous to world AND
mask files.  For packages world + mask files give you possibility to
specify which packages you:

- want (listed in world file)
- don't want (listed in a mask file)
- not care (not listed in any of them)

(Assuming non-explicit approach) similarly for use flags, package.use
or make.conf gives you possibility to specify which use flags you:

- want (listed in package.use or make.conf)
- don't want (listed with '-' in package.use or make.conf)
- not care (not listed in any of them)

The advantage of explicit approach could be that even if a use flag is
enabled or disabled globally, it would still be possible to make it
lazy/automatic for specific packages.

> I can see how some people might want an analogue of "just install
> dependencies if they're needed regardless if I said I need them" that
> applies to useflags, but you'd probably want a "don't install this
> even if it appeared to be needed" companion tool that behaves akin to
> /etc/portage/package.mask

This would be package.use or make.conf.


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/2016 07:08 PM, Gordon Pettey wrote:
> 
> On Tue, Feb 9, 2016 at 7:19 AM, Kent Fredric
> mailto:kentfred...@gmail.com>> wrote:
> 
> On 10 February 2016 at 02:14, Daniel Campbell  > wrote:
>> 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.
> 
> 
> Granted you'd still have the cruft in your config files, but it
> would become mostly-harmless cruft, not cruft that caused needless 
> dependencies to get pulled into the dependency tree as a
> side-effect.
> 
> And because it would be "only as needed", you could afford to use
> some of those "only if needed" useflags in a more global manner.
> 
> For instance, I really don't want to globally define PYTHON_TARGETS
> to include python2_7, because it will simply install a lot of
> extra things I know I don't need.
> 
> But if I could globally define something to the effect of
> "anything that wants python2.7 support can have it", then that's
> acceptable globally, because the effect would still turn things on
> automatically on a per-page level, not at a global level.
> 
> So you could achieve the same results with much less syntax and
> much less effort.
> 
> 
> A distinct behavior for +USE (as opposed to -USE and USE) would
> fit better than "~USE" IMHO, where the plus means "add if (and only
> if) required" and would cascade through dependencies, so if I merge
> e.g. app-portage/pfl with USE="+PYTHON_TARGETS_PYTHON2_7" it would
> apply that to dependencies as required. ~USE might fit for
> something like "~PYTHON_TARGETS_PYTHON3", where it would select the
> greatest flag matching that prefix, and would therefore
> automatically keep packages that have 3_2, 3_3, 3_4, 3_5 using
> whatever is the latest unmasked flag. Could potentially combine the
> prefixes, e.g. "~+PYTHON_TARGETS_PYTHON3" to both select the
> greatest python version AND cascade to dependencies.

The ~ was just a spitballed idea. It's really not important *what* the
symbol is, it's just that one would be required.

- -- 
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

iQIcBAEBCAAGBQJWuq6mAAoJEAEkDpRQOeFwiGsQANMRonEdPVxs5wgG2XFB3bMf
+jTirnBZX0fH4wwaWy7eN5n1oaivepcup7XjUkiXuoqdyZmvZrb1ttwU/vrjaDZn
82rpP+7s9gNqSphifhGcf/EHTZo49VMZUEOBNElj0YtbEa3bcjG/vCpCgxnPuhVr
7LxuTtT0pDZd1mqMBLi+g5XYmDSfls2T2PWO3formcPYs5B3Xf4Dkc2jWEl7mEsB
neDtxkQoXkkuHX3y3uCwXb0KbGKEMenIA+1XiPP9P7nDSaagW+V0DXUWP5aCjTxB
csgiOrOdLEO1305eOkk7kxxoZIRoEgvtlSIA5G0R38+23A0Nwo/F0KV3hMjyBcbi
S6QuMrvwCgWiUIjgzd0zbI1+81EaHErn5zb6asdj78SaC5nzIbmRdw/zI+s4RIm0
8rw6RBsnDsP4Iah/kJHqMBdtDA7my7ImWKkKuWtAfeJfrYheDMb/NwMfl2L7/hIY
jKa0YuZ8P0TnU5xROFlIyXUILXMK/be5KA7RSQe16UMNGLsJLJ/5KBv2KQbJ2fqX
DBQG/780jZBNRAVFRimJ4v1S6g/+BJixN6ajZBe2tBjCV70ina7uL5H1K7cenvE5
0U2M0yl/K9QmEOJQoaR2iwTQL4fbRyr1ntbvlHWwE82rMKdQO2FwJxBj2yhEWELh
CAlwuL8k7LaFGVoQhQhb
=mkla
-END PGP SIGNATURE-

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

[Gordon Pettey]

On Tue, Feb 9, 2016 at 7:19 AM, Kent Fredric  wrote:

> On 10 February 2016 at 02:14, Daniel Campbell  wrote:
> > 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.
>
>
> Granted you'd still have the cruft in your config files, but it would
> become mostly-harmless cruft, not cruft that caused needless
> dependencies to get pulled into the dependency tree as a side-effect.
>
> And because it would be "only as needed", you could afford to use some
> of those "only if needed" useflags in a more global manner.
>
> For instance, I really don't want to globally define PYTHON_TARGETS to
> include python2_7, because it will simply install a lot of extra
> things I know I don't need.
>
> But if I could globally define something to the effect of "anything
> that wants python2.7 support can have it", then that's acceptable
> globally, because the effect would still turn things on automatically
> on a per-page level, not at a global level.
>
> So you could achieve the same results with much less syntax and much
> less effort.
>

A distinct behavior for +USE (as opposed to -USE and USE) would fit better
than "~USE" IMHO, where the plus means "add if (and only if) required" and
would cascade through dependencies, so if I merge e.g. app-portage/pfl with
USE="+PYTHON_TARGETS_PYTHON2_7" it would apply that to dependencies as
required. ~USE might fit for something like "~PYTHON_TARGETS_PYTHON3",
where it would select the greatest flag matching that prefix, and would
therefore automatically keep packages that have 3_2, 3_3, 3_4, 3_5 using
whatever is the latest unmasked flag. Could potentially combine the
prefixes, e.g. "~+PYTHON_TARGETS_PYTHON3" to both select the greatest
python version AND cascade to dependencies.

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

[Kent Fredric]

On 10 February 2016 at 14:12, Rich Freeman  wrote:
>> I'd personally rather the list of "automatically turn this on if
>> required" be something I had the power to restrict than have a blanket
>> "autodostuff", because in the event some USE can't be satisfied, the
>> first time that USE flag was deemed "Needed" I'd want to be told that
>> it was needed, and be prompted to chose a solution.
>
> Wouldn't this be analogous to putting every package you install in
> your world file?


The current situation with "USE" flags is more like having 80% of
portage unavailable due to package.mask/keywords, and where you have
to unmask every package you merely wish to *permit* to be installed,
either by doing it on a per-package level with package.unmask, or
doing it super-globally with ACCEPT_KEYWORDS=

And but even this would be better than the USE situation, because
neither package.mask or the keywording tricks *Force* the package to
be installed, they merely *permit* the package to be installed, and
then depclean can also be relied upon to purge those packages if you
don't put them in your world file.

So in comparison:

/etc/portage/package.use  is essentially "the world file but for useflags"

And we have no analogue of

/etc/porage/package.unmask  or /etc/portage/package.keywords that
applies to useflags.

I can see how some people might want an analogue of "just install
dependencies if they're needed regardless if I said I need them" that
applies to useflags, but you'd probably want a "don't install this
even if it appeared to be needed" companion tool that behaves akin to
/etc/portage/package.mask



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Rich Freeman]

On Tue, Feb 9, 2016 at 7:20 PM, Kent Fredric  wrote:
> I'd personally rather the list of "automatically turn this on if
> required" be something I had the power to restrict than have a blanket
> "autodostuff", because in the event some USE can't be satisfied, the
> first time that USE flag was deemed "Needed" I'd want to be told that
> it was needed, and be prompted to chose a solution.

Wouldn't this be analogous to putting every package you install in
your world file?

--
Rich

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

[Kent Fredric]

On 10 February 2016 at 09:35, Róbert Čerňanský  wrote:
>
> The question is whether you really need to specify the lazy use flag
> explicitly.  I would say that any flag which user did not set
> explicitly to -baz or baz could be considered as lazy use flag.
>
> So if I'd have 'baz' set in /etc/portage/make.conf,
> /etc/portage/package.use, USE environment variable or other user
> configuration then I'd clearly want to turn on baz (globally or for
> specific packages).  Portage would not change the use flag in this
> case (again globally or for particular packages only).
>
> On the other side, if I would not specify 'baz' in any of those user
> configurations (so it would be specified only in profile, ebuild or
> nowhere at all) then I most likely would not care about it therefore
> portage can enable or disable it as needed.
>
> BTW, what you are describing is essentially the same as in this bug:
> https://bugs.gentoo.org/show_bug.cgi?id=258371.  It was also discussed
> on this list couple of times.  I too would very much like to see it in
> portage.

I'd personally rather the list of "automatically turn this on if
required" be something I had the power to restrict than have a blanket
"autodostuff", because in the event some USE can't be satisfied, the
first time that USE flag was deemed "Needed" I'd want to be told that
it was needed, and be prompted to chose a solution.

Because I may choose to:
- Deem the use flag necessary long term and put it hard on
- Deem the use flag and its dependencies unwanted and find an
alternative dependency graph somehow ( which may even include not
installing the package that triggered the bad dependency graph )

An "autodostuff" as opposed to an "autoenable in these conditions" to
me runs against the gentoo "user decides" mentality, because "just
turn on useflags I didn't even tell you to enable" strikes me more as
Portage telling me what I can and can't do, and it might even make me
avoid that feature.

( I don't actually use --autounmask-write for this reason, I peruse
the suggested USE requirements and change my configuration the way I
want it done instead )


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Tim Harder]

On 2016-02-09 15:35, Róbert Čerňanský wrote:

BTW, what you are describing is essentially the same as in this bug:
https://bugs.gentoo.org/show_bug.cgi?id=258371.  It was also discussed
on this list couple of times.  I too would very much like to see it in
portage.


pkgcore's current resolver has supported this for a long time if anyone
really needs this feature now; however, switching to and/or using
pkgcore currently comes with quite a few caveats if one is used to
portage.

Tim


signature.asc
Description: PGP signature

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

[Róbert Čerňanský]

On Wed, 10 Feb 2016 02:19:54 +1300
Kent Fredric  wrote:

> On 10 February 2016 at 02:14, Daniel Campbell  wrote:
> > 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.
> 
> 
> Granted you'd still have the cruft in your config files, but it would
> become mostly-harmless cruft, not cruft that caused needless
> dependencies to get pulled into the dependency tree as a side-effect.
> 
> And because it would be "only as needed", you could afford to use some
> of those "only if needed" useflags in a more global manner.

The question is whether you really need to specify the lazy use flag
explicitly.  I would say that any flag which user did not set
explicitly to -baz or baz could be considered as lazy use flag.

So if I'd have 'baz' set in /etc/portage/make.conf,
/etc/portage/package.use, USE environment variable or other user
configuration then I'd clearly want to turn on baz (globally or for
specific packages).  Portage would not change the use flag in this
case (again globally or for particular packages only).

On the other side, if I would not specify 'baz' in any of those user
configurations (so it would be specified only in profile, ebuild or
nowhere at all) then I most likely would not care about it therefore
portage can enable or disable it as needed.

BTW, what you are describing is essentially the same as in this bug:
https://bugs.gentoo.org/show_bug.cgi?id=258371.  It was also discussed
on this list couple of times.  I too would very much like to see it in
portage.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

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

[Kent Fredric]

On 10 February 2016 at 02:22, Daniel Campbell  wrote:
> I can certainly see the benefit here, but wouldn't that still result
> in (arguably) unnecessary (re)builds? If implemented well it'd also
> result in depcleaning them when they're later unneeded, too, so I
> guess it's a wash in that sense.


For me, its worth it, because the effort I spend to manually dep-clean
use flags I don't need at present is far higher than any
automated cost of rebuild will burn me.

I've even recently started using `--with-bdeps n` in conjunction with
--depclean ( because tip, depclean implies --with-bdeps y ), because I
don't mind the rebuild cost, and I much more mind the significant
dependency graph I have sitting around there not earning its weight.

And the beauty of this is you woudn't pay a cent in terms of unwanted
behaviour from the introduction of this feature unless you explicitly
used it.

You'd have to be intentionally using the lazy-use flags to see the
undesired rebuild effect, and if that bothers you, its easy to just
transition a soft-use into a hard use, just like if you don't like how
depclean nukes a package, you can add it to your world file.



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/2016 05:19 AM, Kent Fredric wrote:
> On 10 February 2016 at 02:14, Daniel Campbell 
> wrote:
>> 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.
> 
> 
> Granted you'd still have the cruft in your config files, but it
> would become mostly-harmless cruft, not cruft that caused needless 
> dependencies to get pulled into the dependency tree as a
> side-effect.
> 
> And because it would be "only as needed", you could afford to use
> some of those "only if needed" useflags in a more global manner.
> 
> For instance, I really don't want to globally define PYTHON_TARGETS
> to include python2_7, because it will simply install a lot of
> extra things I know I don't need.
> 
> But if I could globally define something to the effect of
> "anything that wants python2.7 support can have it", then that's
> acceptable globally, because the effect would still turn things on
> automatically on a per-page level, not at a global level.
> 
> So you could achieve the same results with much less syntax and
> much less effort.
> 

I can certainly see the benefit here, but wouldn't that still result
in (arguably) unnecessary (re)builds? If implemented well it'd also
result in depcleaning them when they're later unneeded, too, so I
guess it's a wash in that sense.

Again, I'm not against it. In fact I'd probably use it, because some
packages are really picky. I just don't know how well it would fit
into the existing design at the code level.

- -- 
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

iQIcBAEBCAAGBQJWuegpAAoJEAEkDpRQOeFwoYIQALeAXnPOXzrC10AWplSt0K9D
O3Mp8KpiMMUfIi1neM2LQAfW6Kp3lA9CaA547TdJ2ZXBJdTSfwPMe5rsWY2wqavD
UvASgl4Ja4molsM3mQX3rYWbbzjZN38mZmYby26mPwyo8kAeXeqqIFDpPyG3F11M
0uT0lCg8W6q6qs00l02SZHmQKGQwCL4JLXNe9mj8WLcoaeMZjXwDCS3lhLz2L7at
bveIm/yk5JaPSc3i8zcwmjDyoJ2fQg+1u2ujl+MzgVcxY8pfSnJN0q4CV06rC4xt
7F65OU8DhzaNr80UUfKCNdfVXwIlDNIEK1mz/tRe3Ad4bW1NW5DJFpm9xjpSPSlD
Cse2GNBTxKYDi/mxlLBenCyqHta05TyzdqDODiOJRMzIXRf2jcPtOkg58tdUMl8D
xw/qIFwcUeC44RfX9Kb9NkQcxuhyuLSPBcnGGdxeaUtJf92wpw4AINfSLj2B8nwv
XyPan9bGku6gsG6C5oQ0JUsGdNu/qmukUieppE4yKbFgjzoIZcuOb18jKyDaxVKh
QiQ9uI2xGvQYqAHVAraykAoBEl7EHISRRLn508VB8WZUxV39q5BwYtpYrxAJtSEY
60NuTTKmU7CXK4czHukrKPpkwkqNGIBgK1/m7dVpXjxcXfk/cdcwilv3EmO7f6fb
XKundbhCB5ek42OGqTuG
=+Yx3
-END PGP SIGNATURE-

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

[Kent Fredric]

On 10 February 2016 at 02:14, Daniel Campbell  wrote:
> 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.


Granted you'd still have the cruft in your config files, but it would
become mostly-harmless cruft, not cruft that caused needless
dependencies to get pulled into the dependency tree as a side-effect.

And because it would be "only as needed", you could afford to use some
of those "only if needed" useflags in a more global manner.

For instance, I really don't want to globally define PYTHON_TARGETS to
include python2_7, because it will simply install a lot of extra
things I know I don't need.

But if I could globally define something to the effect of "anything
that wants python2.7 support can have it", then that's acceptable
globally, because the effect would still turn things on automatically
on a per-page level, not at a global level.

So you could achieve the same results with much less syntax and much
less effort.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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 SIGN

[gentoo-dev] "Lazy" use flags?

[Kent Fredric]

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.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL