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?

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

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

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

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

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

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

[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: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?

[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] Changing order of default virtual/udev provider

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/02/16 08:46 PM, Nicolas Sebrecht wrote:
> On Mon, Feb 08, 2016 at 11:00:15AM -0500, Ian Stakenvicius
> wrote:
> 
>> Oh, eudev also doesn't handle network link setup given that
>> external tools already do this just fine.  That's another
>> difference, though not one that matters programmatically.  That
>> said, the network-link setup was added primarily to support
>> systemd's use-case, and there's very little need or point in
>> having it done by udevd on an rc-based system.
> 
> Unless I'm mistaken, you're saying that eudev doesn't handle
> network link but it doesn't matter because rc-based systems don't
> requires it.
> 
> And at the same time, I read in this thread that eudev is
> in-place replacement for udev without any harm. What will happen
> to the users wanting systemd AND expect the network link setup?
> 

Systemd requires system configuration differently compared to
openrc and other rc systems.  One cannot expect eudev (or sys-fs/udev)
to be drop-in replacements for systemd and for them to read systemd
configuration.  See
https://www.freedesktop.org/software/systemd/man/systemd.link.html
for more information on network linking, especially the very
systemd-specific config locations.

If someone whats to use both openrc and systemd on the same system,
then they can't have EITHER sys-fs/udev OR sys-fs/eudev installed,
so the point to this particular discussion is rather moot.
Systemd-udev from the systemd package could theoretically read the
network-link config files, assuming that systemd doesn't need to be
PID1 for this to occur; it could very well be, however, that even
when systemd is installed, booting openrc the network link setup
will still need to be configured appropriately outside of these
systemd configs.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAla8uewACgkQAJxUfCtlWe2nBgEAoelTVLQLwhqrrqNFGUncmW3M
iSrWyWSMlKTgeltsNQIBAOjewM3i0enEzhYacRijzmdNkrJdzs5KrYca3Ze1dftw
=1nVy
-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

[gentoo-dev] Uncoordinated changes

[Patrick Lauer]

... or why just changing stuff is not enough:

A few days ago I was told that
http://euscan.gentooexperimental.org/herds/ was displaying an empty
list. Which is annoying because people sometimes want to see what
upstream updates are available for their herd.

Well, we renamed herd to project. Because reasons.

I don't care how it is named, but this change broke euscan in a
user-visible way. Now I could just try to rename things there too, but
that won't work:

euscan uses gentoolkit for parsing metadata.xml and herds.xml
(Since herds.xml is basically unmaintained cruft at this point this will
break soon anyway ... but ...)
Changing gentoolkit to use projects.xml instead of herds.xml won't be a
simple migration since the data organization changed.

Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
-> email it goes backwards:
[metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
-> Project name

Since this involves XML and python's ElementTree library it's a
nontrivial change that also removes a few now useless helpers
(_get_herd_email has no reason to be, but we'd need a _get_herd_name
helper instead. Err, get_proj ... ah well, whatever name works)

And all that just so (1) gentoolkit output works and (2) euscan updates
properly. Both of which I don't really care about much, but now that
I've invested ~4h into debugging and trying to fix it I'm a tiny bit
IRRITATED.



Please, next time someone has the brilliant idea of changing stuff just
to change it (I still don't see a reason why we had to change
metadata.xml?), it should be required that support tools are fixed
*before* the change, and working versions released. This avoids grumpy
people and makes it harder for those that change things to head-in-sand
and claim everything works as expected when it obviously doesn't.


And this, again, supports my default phrase: "Change is not Progress",
because now we have regressions and user-visible breakage, and it's hard
to qualify how the change actually improved anything because we haven't
actually *finished* the change. (Like the git migration that is still
ongoing ...)

Do the needfull! Be of excellent moral person!

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?

[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: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?

[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 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] Uncoordinated changes

[Rich Freeman]

On Thu, Feb 11, 2016 at 3:15 PM, Patrick Lauer  wrote:
>
> Please, next time someone has the brilliant idea of changing stuff just
> to change it (I still don't see a reason why we had to change
> metadata.xml?), it should be required that support tools are fixed
> *before* the change, and working versions released. This avoids grumpy
> people and makes it harder for those that change things to head-in-sand
> and claim everything works as expected when it obviously doesn't.
>

A few comments:
This change has been a long time in the making, with plenty of notice.
It even went through the formal GLEP process.  It isn't like there
wasn't ample notice.

If we didn't allow anybody to make any change without taking upon
themselves the responsibility to fix any tool anybody had created that
would be affected, then nobody would change anything, and we'd be
reduced to bitrot.  If anything I think the rate of change in Gentoo
is probably a bit low.  I don't propose changing things for the sake
of change, but contributors should feel free to propose changes and
not expect that they will have to shoulder 100% of the burden of
completely supporting those changes.

It is far more reasonable to provide notice of change, and then the
onus is on those who want specific tools to work to fix them.  If
there is a concern that more time is needed/etc this could be raised
with the council before the change.  I'm sure if the eudev maintainers
had raised a concern at any point the council would have worked with
them.

Ultimately, the only way anybody can be assured that their favorite
Gentoo tool will work in a year is if they're maintaining it.  It
sounds like nobody was really paying attention to it, which is why
nobody noticed that it was going to break.

--
Rich

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

[gentoo-dev] Last rites: media-libs/gluon

[Michael Palimaka]

# Michael Palimaka  (12 Feb 2016)
# Fails to build. No revdeps. Masked for removal in 30 days.
# Bug 574432
media-libs/gluon

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

[Duncan]

Rich Freeman posted on Thu, 11 Feb 2016 07:55:52 -0500 as excerpted:

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

So my USE="-* ..." (without letting portage do autounmasking) would 
continue to work just like it does now, correct?

Because I allow neither profile USE flags nor profile @system packages  
(all such profile entries and package-based default-use are negated), 
here, and my package.use files contain only specific exceptions to my 
global USE policy settings, together with (generally date-stamped) 
comments justifying exactly why that exception is there.

By definition, then, If I haven't specifically set USE=flag, my system 
policy is USE=-flag, and I want to know about and specifically setup any 
exceptions (or if justified change my system policy), so I can set the 
justification notes at the same time.

Because I'd be rather put out at anyone suggesting that I have to 
specifically -flag each individual flag I want to be hard off, not 
squishy off, as that's all the flags I've not specifically set hard on.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Kent Fredric]

On 12 February 2016 at 18:56, Duncan <1i5t5.dun...@cox.net> wrote:
> So my USE="-* ..." (without letting portage do autounmasking) would
> continue to work just like it does now, correct?


I would hope so. And obviously, this feature would be potentially
tenous, and might be wise to only
activate its mechanics with a parameter to emerge.

That is, I suggest that unless you have

--lazy-use

In your emerge opts, no lazy use mechanics should be applied ( or even
considered )

That way, people who do want the  new behaviour can stick it in the
default emerge options and \o/

-- 
Kent

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

Re: [gentoo-dev] Uncoordinated changes

[Michał Górny]

Dear Ignorant Patrick,

On Thu, 11 Feb 2016 21:15:34 +0100
Patrick Lauer  wrote:

> ... or why just changing stuff is not enough:
> 
> A few days ago I was told that
> http://euscan.gentooexperimental.org/herds/ was displaying an empty
> list. Which is annoying because people sometimes want to see what
> upstream updates are available for their herd.
> 
> Well, we renamed herd to project. Because reasons.

No, we didn't. Herd was collection a packages. Project is a collection
of developers. Project coexisted with herds for a long time. As it was
explained already in length. Multiple times.

> I don't care how it is named, but this change broke euscan in a
> user-visible way. Now I could just try to rename things there too, but
> that won't work:
> 
> euscan uses gentoolkit for parsing metadata.xml and herds.xml
> (Since herds.xml is basically unmaintained cruft at this point this will
> break soon anyway ... but ...)
> Changing gentoolkit to use projects.xml instead of herds.xml won't be a
> simple migration since the data organization changed.
> 
> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
> -> email it goes backwards:  
> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
> -> Project name  
> 
> Since this involves XML and python's ElementTree library it's a
> nontrivial change that also removes a few now useless helpers
> (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> helper instead. Err, get_proj ... ah well, whatever name works)
> 
> And all that just so (1) gentoolkit output works and (2) euscan updates
> properly. Both of which I don't really care about much, but now that
> I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> IRRITATED.

You are completely incorrect, as you have been told already multiple
times. People would really appreciate if you spent at least a little
part of the time you spend complaining, inventing issues and insulting
others listening to what they're telling you.

So let me repeat, again. euscan works. Want packages from Python
project? Then select the appropriate maintainer from the 'maintainers'
section:

http://euscan.gentooexperimental.org/maintainers/pyt...@gentoo.org/

Done. Was it that hard? Now the big surprise: you didn't have to create
some convoluted logic to get that! You don't need projects.xml to get
that! Of course, you'd know that if you would listen for a single
minute instead of throwing insults at others.

> Please, next time someone has the brilliant idea of changing stuff just
> to change it (I still don't see a reason why we had to change
> metadata.xml?), it should be required that support tools are fixed
> *before* the change, and working versions released. This avoids grumpy
> people and makes it harder for those that change things to head-in-sand
> and claim everything works as expected when it obviously doesn't.

The fact is: things *work as expected*. If you have problem accepting
reality as it is, then it's your fault, not ours. Herds no longer
exist. Everything is based on *maintainers* now. Tools are not supposed
to magically turn project information back into herd-oriented design.

As I said before, please direct any further complaints directly to
the Council, and stop insulting the messenger. The Council has banned
herds explicitly before I even started working on GLEP 67. It was
the guideline I had to follow.

-- 
Best regards,
Michał Górny



pgpymAMGWZmYX.pgp
Description: OpenPGP digital signature