[gentoo-dev] useflag policies

[gentoo-dev] useflag policies

[Ben de Groot]

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

Recently some team members of the Qt project have adopted these ebuild
policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies

I have an issue with the policy adopted under "Requires one of two Qt
versions". In my opinion, in the case where a package offers a choice
between qt4 or qt5, we should express this in explicit useflags and a
REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice.

Other developers state that users are not interested in such implementation
details, or that forced choice through REQUIRED_USE is too much of a
hassle. This results in current ebuilds such as quassel to not make it
clear that qt4 is an option.

This goes against the principle of least surprise, as well as against QA
recommendations. I would like to hear specifically from QA about how we
should proceed, but comments from the wider developer community are also
welcome.

-- 
Cheers,

Ben | yngwin
Gentoo developer

[-- Attachment #2: Type: text/html, Size: 1128 bytes --]

Re: [gentoo-dev] useflag policies

[Michał Górny]

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

Dnia 2015-08-03, o godz. 00:34:51
Ben de Groot <yngwin@gentoo.org> napisał(a):

> Recently some team members of the Qt project have adopted these ebuild
> policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies
> 
> I have an issue with the policy adopted under "Requires one of two Qt
> versions". In my opinion, in the case where a package offers a choice
> between qt4 or qt5, we should express this in explicit useflags and a
> REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice.
> 
> Other developers state that users are not interested in such implementation
> details, or that forced choice through REQUIRED_USE is too much of a
> hassle. This results in current ebuilds such as quassel to not make it
> clear that qt4 is an option.
> 
> This goes against the principle of least surprise, as well as against QA
> recommendations. I would like to hear specifically from QA about how we
> should proceed, but comments from the wider developer community are also
> welcome.

Long story short, this is USE=gtk once again. GNOME team had a
policy that handled the case cleanly and QA outvoted it in favor of
Qt-like policy. Then Qt team figured out their policy was unfriendly,
and 'fixed' it with this ugly hack...

As I see it, this is a major failure of using toolkit-version oriented
flags rather than feature-oriented flags. Possibilities compared:

USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE
issues. However, it's ugly: USE='qt4 qt5' may now mean either both
toolkits or one of them. In the latter case, we have two flag
combinations (= two different binary packages) that mean the same.
Additionally, USE='-qt4 -qt5' may mean both none of them or one of
them. If the latter, yet another case of redundant binary package.

USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better
for binary packages. However, it may mean that user will have to
randomly adjust flags per-package. Which may end up sucking even more
with new Qt versions being introduced and package.use being full of
random '-qt4' and stuff.

What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
team policy. USE=qt would mean 'any version of Qt, if optional', and
qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
obligatory, no USE=qt would apply. If only one Qt version would be
supported, no USE=qt4/qt5 would apply. Clean, sane and limited
package.use cruft.

However, as you can see QA has previously outvoted the clean policy for
USE=gtk. I don't see why it would decide otherwise for USE=qt*.

--
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] useflag policies

["Paweł Hajdan, Jr."]

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

On 8/2/15 7:27 PM, Michał Górny wrote:
> What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
> team policy. USE=qt would mean 'any version of Qt, if optional', and
> qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
> obligatory, no USE=qt would apply. If only one Qt version would be
> supported, no USE=qt4/qt5 would apply. Clean, sane and limited
> package.use cruft.

+1

> However, as you can see QA has previously outvoted the clean policy for
> USE=gtk. I don't see why it would decide otherwise for USE=qt*.

I wonder what was the reasoning for the QA decision you refer to. Do you
have more details or archive references?

FWIW I think decisions like that can be revisited. Now could be a good
moment for that.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: [gentoo-dev] useflag policies

[Andrew Savchenko]

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

On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote:
> Long story short, this is USE=gtk once again. GNOME team had a
> policy that handled the case cleanly and QA outvoted it in favor of
> Qt-like policy. Then Qt team figured out their policy was unfriendly,
> and 'fixed' it with this ugly hack...
> 
> As I see it, this is a major failure of using toolkit-version oriented
> flags rather than feature-oriented flags. Possibilities compared:
> 
> USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE
> issues. However, it's ugly: USE='qt4 qt5' may now mean either both
> toolkits or one of them. In the latter case, we have two flag
> combinations (= two different binary packages) that mean the same.
> Additionally, USE='-qt4 -qt5' may mean both none of them or one of
> them. If the latter, yet another case of redundant binary package.
> 
> USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better
> for binary packages. However, it may mean that user will have to
> randomly adjust flags per-package. Which may end up sucking even more
> with new Qt versions being introduced and package.use being full of
> random '-qt4' and stuff.
> 
> What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
> team policy. USE=qt would mean 'any version of Qt, if optional', and
> qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
> obligatory, no USE=qt would apply. If only one Qt version would be
> supported, no USE=qt4/qt5 would apply. Clean, sane and limited
> package.use cruft.

This is a clean solution for developers and maintainers, but not
for ordinary users — they will confused by "qt qt4 qt5": "what is
'qt', how is it different from 'qt4' and 'qt5'. What you are really
doing is implementing second-level USE flags, while they were
supposed to be linear.

> However, as you can see QA has previously outvoted the clean policy for
> USE=gtk. I don't see why it would decide otherwise for USE=qt*.
> 
> --
> Best regards,
> Michał Górny


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] useflag policies

[Michał Górny]

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

Dnia 2015-08-02, o godz. 21:21:03
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote:
> > Long story short, this is USE=gtk once again. GNOME team had a
> > policy that handled the case cleanly and QA outvoted it in favor of
> > Qt-like policy. Then Qt team figured out their policy was unfriendly,
> > and 'fixed' it with this ugly hack...
> > 
> > As I see it, this is a major failure of using toolkit-version oriented
> > flags rather than feature-oriented flags. Possibilities compared:
> > 
> > USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE
> > issues. However, it's ugly: USE='qt4 qt5' may now mean either both
> > toolkits or one of them. In the latter case, we have two flag
> > combinations (= two different binary packages) that mean the same.
> > Additionally, USE='-qt4 -qt5' may mean both none of them or one of
> > them. If the latter, yet another case of redundant binary package.
> > 
> > USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better
> > for binary packages. However, it may mean that user will have to
> > randomly adjust flags per-package. Which may end up sucking even more
> > with new Qt versions being introduced and package.use being full of
> > random '-qt4' and stuff.
> > 
> > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
> > team policy. USE=qt would mean 'any version of Qt, if optional', and
> > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
> > obligatory, no USE=qt would apply. If only one Qt version would be
> > supported, no USE=qt4/qt5 would apply. Clean, sane and limited
> > package.use cruft.
> 
> This is a clean solution for developers and maintainers, but not
> for ordinary users — they will confused by "qt qt4 qt5": "what is
> 'qt', how is it different from 'qt4' and 'qt5'.

This can be easily fixed via USE flag descriptions. And unlike with
your solution, the descriptions can be globally consistent.

> What you are really
> doing is implementing second-level USE flags, while they were
> supposed to be linear.

Please support such claims with references.

--
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] useflag policies

[Andrew Savchenko]

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

On Sun, 2 Aug 2015 20:35:27 +0200 Michał Górny wrote:
> Dnia 2015-08-02, o godz. 21:21:03
> Andrew Savchenko <bircoph@gentoo.org> napisał(a):
> 
> > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote:
> > > Long story short, this is USE=gtk once again. GNOME team had a
> > > policy that handled the case cleanly and QA outvoted it in favor of
> > > Qt-like policy. Then Qt team figured out their policy was unfriendly,
> > > and 'fixed' it with this ugly hack...
> > > 
> > > As I see it, this is a major failure of using toolkit-version oriented
> > > flags rather than feature-oriented flags. Possibilities compared:
> > > 
> > > USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE
> > > issues. However, it's ugly: USE='qt4 qt5' may now mean either both
> > > toolkits or one of them. In the latter case, we have two flag
> > > combinations (= two different binary packages) that mean the same.
> > > Additionally, USE='-qt4 -qt5' may mean both none of them or one of
> > > them. If the latter, yet another case of redundant binary package.
> > > 
> > > USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better
> > > for binary packages. However, it may mean that user will have to
> > > randomly adjust flags per-package. Which may end up sucking even more
> > > with new Qt versions being introduced and package.use being full of
> > > random '-qt4' and stuff.
> > > 
> > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
> > > team policy. USE=qt would mean 'any version of Qt, if optional', and
> > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
> > > obligatory, no USE=qt would apply. If only one Qt version would be
> > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited
> > > package.use cruft.
> > 
> > This is a clean solution for developers and maintainers, but not
> > for ordinary users — they will confused by "qt qt4 qt5": "what is
> > 'qt', how is it different from 'qt4' and 'qt5'.
> 
> This can be easily fixed via USE flag descriptions. And unlike with
> your solution, the descriptions can be globally consistent.
> 
> > What you are really
> > doing is implementing second-level USE flags, while they were
> > supposed to be linear.
> 
> Please support such claims with references.

A reference from your previous e-mail:
> > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote:
[...]
> > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
> > > team policy. USE=qt would mean 'any version of Qt, if optional', and
> > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
> > > obligatory, no USE=qt would apply. If only one Qt version would be
> > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited
> > > package.use cruft.

You're proposing "qt" as a top level USE flag, while "qt4/qt5" will
be in your opinion optional clarifying USE flags. This way we have
second-level hierarchy.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] useflag policies

[Michał Górny]

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

Dnia 2015-08-02, o godz. 21:50:25
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Sun, 2 Aug 2015 20:35:27 +0200 Michał Górny wrote:
> > Dnia 2015-08-02, o godz. 21:21:03
> > Andrew Savchenko <bircoph@gentoo.org> napisał(a):
> > 
> > > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote:
> > > > Long story short, this is USE=gtk once again. GNOME team had a
> > > > policy that handled the case cleanly and QA outvoted it in favor of
> > > > Qt-like policy. Then Qt team figured out their policy was unfriendly,
> > > > and 'fixed' it with this ugly hack...
> > > > 
> > > > As I see it, this is a major failure of using toolkit-version oriented
> > > > flags rather than feature-oriented flags. Possibilities compared:
> > > > 
> > > > USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE
> > > > issues. However, it's ugly: USE='qt4 qt5' may now mean either both
> > > > toolkits or one of them. In the latter case, we have two flag
> > > > combinations (= two different binary packages) that mean the same.
> > > > Additionally, USE='-qt4 -qt5' may mean both none of them or one of
> > > > them. If the latter, yet another case of redundant binary package.
> > > > 
> > > > USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better
> > > > for binary packages. However, it may mean that user will have to
> > > > randomly adjust flags per-package. Which may end up sucking even more
> > > > with new Qt versions being introduced and package.use being full of
> > > > random '-qt4' and stuff.
> > > > 
> > > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
> > > > team policy. USE=qt would mean 'any version of Qt, if optional', and
> > > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
> > > > obligatory, no USE=qt would apply. If only one Qt version would be
> > > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited
> > > > package.use cruft.
> > > 
> > > This is a clean solution for developers and maintainers, but not
> > > for ordinary users — they will confused by "qt qt4 qt5": "what is
> > > 'qt', how is it different from 'qt4' and 'qt5'.
> > 
> > This can be easily fixed via USE flag descriptions. And unlike with
> > your solution, the descriptions can be globally consistent.
> > 
> > > What you are really
> > > doing is implementing second-level USE flags, while they were
> > > supposed to be linear.
> > 
> > Please support such claims with references.
> 
> A reference from your previous e-mail:
> > > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote:
> [...]
> > > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
> > > > team policy. USE=qt would mean 'any version of Qt, if optional', and
> > > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
> > > > obligatory, no USE=qt would apply. If only one Qt version would be
> > > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited
> > > > package.use cruft.
> 
> You're proposing "qt" as a top level USE flag, while "qt4/qt5" will
> be in your opinion optional clarifying USE flags. This way we have
> second-level hierarchy.

I meant the claim that USE flags are supposed to be linear.

--
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] useflag policies

[Rich Freeman]

On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> This is a clean solution for developers and maintainers, but not
> for ordinary users — they will confused by "qt qt4 qt5": "what is
> 'qt', how is it different from 'qt4' and 'qt5'. What you are really
> doing is implementing second-level USE flags, while they were
> supposed to be linear.

No argument that it isn't intuitive, but setting USE=qt and forgetting
about it certainly seems more user-friendly than setting qt4/qt5 on
individual packages and worrying about which is better where.  To some
extent the current qt policy accomplishes this, but it sacrifices
control when users actually do want it.

I'm a bit torn on the issue myself, but just telling users to set
USE=qt and forget about it unless you really care seems pretty simple
to me.  The documentation for USE=qt4/qt5 could say "this is an
advanced setting for users who want to prefer the qt4 implementation
over others - set USE=qt if all you care about is qt support."

-- 
Rich

Re: [gentoo-dev] useflag policies

[Davide Pesavento]

On Sun, Aug 2, 2015 at 12:12 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>>
>> This is a clean solution for developers and maintainers, but not
>> for ordinary users — they will confused by "qt qt4 qt5": "what is
>> 'qt', how is it different from 'qt4' and 'qt5'. What you are really
>> doing is implementing second-level USE flags, while they were
>> supposed to be linear.
>
> No argument that it isn't intuitive, but setting USE=qt and forgetting
> about it certainly seems more user-friendly than setting qt4/qt5 on
> individual packages and worrying about which is better where.  To some
> extent the current qt policy accomplishes this, but it sacrifices
> control when users actually do want it.

No, it does not. You can still control whether you want qt4 or qt5 on
a per-package basis. The difference is that users that don't care
about this level of control are not forced to make a choice for every
package due to REQUIRED_USE conflicts. Unless I'm missing something...

Re: [gentoo-dev] useflag policies

[Daniel Campbell (zlg)]

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

On 08/02/2015 12:12 PM, Rich Freeman wrote:
> On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko
> <bircoph@gentoo.org> wrote:
>> 
>> This is a clean solution for developers and maintainers, but not 
>> for ordinary users — they will confused by "qt qt4 qt5": "what
>> is 'qt', how is it different from 'qt4' and 'qt5'. What you are
>> really doing is implementing second-level USE flags, while they
>> were supposed to be linear.
> 
> No argument that it isn't intuitive, but setting USE=qt and
> forgetting about it certainly seems more user-friendly than setting
> qt4/qt5 on individual packages and worrying about which is better
> where.  To some extent the current qt policy accomplishes this, but
> it sacrifices control when users actually do want it.
> 
> I'm a bit torn on the issue myself, but just telling users to set 
> USE=qt and forget about it unless you really care seems pretty
> simple to me.  The documentation for USE=qt4/qt5 could say "this is
> an advanced setting for users who want to prefer the qt4
> implementation over others - set USE=qt if all you care about is qt
> support."
> 
I like this idea. USE=qt for all apps that optionally support or need
it, qt4/qt5 for apps that support both. We can default to qt5 and
users can still choose qt4 if they prefer it.

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

iQIcBAEBCAAGBQJVvxjcAAoJEAEkDpRQOeFwbIsQAJeCSW9NHUFyXirEhh/pL7cP
Vc5F6bgxZhJ1svHiCxMAQuFz5POG/yxjq6iAwjtCaDaWBDj/HbSDe69Pu0HBcCkK
ezb2AJTtacvkWDxlJhH4H9m7QB3M9/XWlKlfMAhKnDEaSFS/yieR578LE1sNd2aF
A9JditTliVqmRr3DYNvT4JlqGIBJyU43gR75gW2gHyWE0FTZ4Rv8k6DQHJuseFb6
OvWWrDCKZQZqLmLIvpvz1ksyXuFis8qqCPLws37awo56kjT8jDJ+kdulwFGdvxui
zrau+MtufhDwehVsVKKe1j/6dhVnmOqlIZd3H7Pule9jFsH6AGRN4s2dL2bp9vqi
WdmQI8B6eDvdUK0Il1+zd7V1Uq8DXIYpTlOYrUHtnAlyaT8ln7FqojSKODASZ/10
LkJQ9SLv7ej6nQLnkYe4F1FQqssPqGe4v2tAZcFVu2pYda3KCP7PJKT70oFtzwrQ
76jVgp5Ryp/cbZrM2tOEcvb/3kTXDHDW2Wavh+VV7XwBmTvXoXqZas+eHMMtbyDJ
1cofAFRvu6HWnITTg3ZPoiQbm5Sq4rjG7aUvkyUxIoC8YzhXdHOTBpaYaFe6nZ/f
45e7lHq4iDsArmBn2BiF4kBKZh8I5xMY1/K10mC8/4emBS3NHbafOUKqujCCqLMj
dhh/jF4gLzALPIDGXBRp
=j7X5
-----END PGP SIGNATURE-----

Re: [gentoo-dev] useflag policies

[Davide Pesavento]

On Sun, Aug 2, 2015 at 10:27 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2015-08-03, o godz. 00:34:51
> Ben de Groot <yngwin@gentoo.org> napisał(a):
>
>> Recently some team members of the Qt project have adopted these ebuild
>> policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies
>>
>> I have an issue with the policy adopted under "Requires one of two Qt
>> versions". In my opinion, in the case where a package offers a choice
>> between qt4 or qt5, we should express this in explicit useflags and a
>> REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice.
>>
>> Other developers state that users are not interested in such implementation
>> details, or that forced choice through REQUIRED_USE is too much of a
>> hassle. This results in current ebuilds such as quassel to not make it
>> clear that qt4 is an option.
>>
>> This goes against the principle of least surprise, as well as against QA
>> recommendations. I would like to hear specifically from QA about how we
>> should proceed, but comments from the wider developer community are also
>> welcome.
>
> Long story short, this is USE=gtk once again. GNOME team had a
> policy that handled the case cleanly and QA outvoted it in favor of
> Qt-like policy. Then Qt team figured out their policy was unfriendly,
> and 'fixed' it with this ugly hack...

Except that it's not a "ugly hack", but it's in fact recommended by
the devmanual (ulm already quoted the relevant text). I'd agree that
it's not ideal either (but so far I haven't seen any ideal solution
being proposed).

> As I see it, this is a major failure of using toolkit-version oriented
> flags rather than feature-oriented flags. Possibilities compared:

I could agree with this. So, back to USE=gui? A USE_EXPAND maybe?

> What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
> team policy. USE=qt would mean 'any version of Qt, if optional', and
> qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
> obligatory, no USE=qt would apply. If only one Qt version would be
> supported, no USE=qt4/qt5 would apply. Clean, sane and limited
> package.use cruft.
>

I could agree in principle. However this would be a major tree-wide
change, and should happen as quickly as possible to avoid creating
even more confusion for users. Plus, who is willing to do all the
work? (hint: I'm not) ...so, I don't think this solution is practical.

Re: [gentoo-dev] useflag policies

[Andrew Savchenko]

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

On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote:
> Recently some team members of the Qt project have adopted these ebuild
> policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies
> 
> I have an issue with the policy adopted under "Requires one of two Qt
> versions". In my opinion, in the case where a package offers a choice
> between qt4 or qt5, we should express this in explicit useflags

This is what the policy does:
"Implement both qt4 and qt5 USE flags"

> and a
> REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice.

This will create insane amount of blockers if users have both flags
in make.conf (and this is a common scenario).

> Other developers state that users are not interested in such implementation
> details, or that forced choice through REQUIRED_USE is too much of a
> hassle. This results in current ebuilds such as quassel to not make it
> clear that qt4 is an option.
> 
> This goes against the principle of least surprise, as well as against QA
> recommendations. I would like to hear specifically from QA about how we
> should proceed, but comments from the wider developer community are also
> welcome.
 
As far as I understand this is done to simplify user's experiense:
usually people set both USE="qt4 qt5" in global make.conf, because
they want qt in the first place.

This policy will allow to USE both qt versions whichever is
available preferring newer one. Quite reasonable approach.
Alternatives (^^() and ??()) will require micromanagement (e.g.
pagkage.use.conf) for dozens if not hundreds of packages for no
good reason. If someone still needs to override such policy (e.g.
to use qt4 when both are available), this can be done by
per-package configuration.

My idea is that packages should be fully controllable, but choises
of default behaviour should be done so, that in most cases
micromanagement will not be necessary.

I like this qt policy and I'm not sure if it violates any current
rule. But even in such case this rule should be fixed. Moreover,
this problem is not limited for qt: we have exactly the same issue
with gtk2 vs gtk3 and probably some other technologies.

Of course in theory it is possible to build package with two sets
of binaries supporting both qt4 and qt5, but I see little practical
need for that.

So I propose to add somewhere to devmanual/policies the following
recommendation: "If package supports several versions of the same
technology (e.g. qt4 and qt5) and more than one is enabled by USE
flags, ebuild should prefer the later one (in terms of technology
generation).".

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] useflag policies

[Ben de Groot]

On 3 August 2015 at 01:33, Andrew Savchenko <bircoph@gentoo.org> wrote:
> On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote:
> [...]
> This policy will allow to USE both qt versions whichever is
> available preferring newer one. Quite reasonable approach.
> Alternatives (^^() and ??()) will require micromanagement (e.g.
> pagkage.use.conf) for dozens if not hundreds of packages for no
> good reason. If someone still needs to override such policy (e.g.
> to use qt4 when both are available), this can be done by
> per-package configuration.
>
> My idea is that packages should be fully controllable, but choises
> of default behaviour should be done so, that in most cases
> micromanagement will not be necessary.
>
> I like this qt policy and I'm not sure if it violates any current
> rule.

See https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies
under 1.4 and 1.5.

QA has spoken out pretty clearly against unversioned gtk or qt
useflags, and in favour of explicit versioned useflags. Dropping the
explicit qt4 useflag in these cases goes against (at least the spirit
of) this.

> [...]
> So I propose to add somewhere to devmanual/policies the following
> recommendation: "If package supports several versions of the same
> technology (e.g. qt4 and qt5) and more than one is enabled by USE
> flags, ebuild should prefer the later one (in terms of technology
> generation).".

If we adopt this, we should make sure the users understand this
policy, because it hides certain details from the user.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] useflag policies

[Daniel Campbell (zlg)]

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

On 08/02/2015 10:33 AM, Andrew Savchenko wrote:
> On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote:
>> Recently some team members of the Qt project have adopted these
>> ebuild policies:
>> https://wiki.gentoo.org/wiki/Project:Qt/Policies
>> 
>> I have an issue with the policy adopted under "Requires one of
>> two Qt versions". In my opinion, in the case where a package
>> offers a choice between qt4 or qt5, we should express this in
>> explicit useflags
> 
> This is what the policy does: "Implement both qt4 and qt5 USE
> flags"
> 
>> and a REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the
>> clearest choice.
> 
> This will create insane amount of blockers if users have both
> flags in make.conf (and this is a common scenario).
> 
>> Other developers state that users are not interested in such
>> implementation details, or that forced choice through
>> REQUIRED_USE is too much of a hassle. This results in current
>> ebuilds such as quassel to not make it clear that qt4 is an
>> option.
>> 
>> This goes against the principle of least surprise, as well as
>> against QA recommendations. I would like to hear specifically
>> from QA about how we should proceed, but comments from the wider
>> developer community are also welcome.
> 
> As far as I understand this is done to simplify user's experiense: 
> usually people set both USE="qt4 qt5" in global make.conf, because 
> they want qt in the first place.
> 
> This policy will allow to USE both qt versions whichever is 
> available preferring newer one. Quite reasonable approach. 
> Alternatives (^^() and ??()) will require micromanagement (e.g. 
> pagkage.use.conf) for dozens if not hundreds of packages for no 
> good reason. If someone still needs to override such policy (e.g. 
> to use qt4 when both are available), this can be done by 
> per-package configuration.
> 
> My idea is that packages should be fully controllable, but choises 
> of default behaviour should be done so, that in most cases 
> micromanagement will not be necessary.
> 
> I like this qt policy and I'm not sure if it violates any current 
> rule. But even in such case this rule should be fixed. Moreover, 
> this problem is not limited for qt: we have exactly the same issue 
> with gtk2 vs gtk3 and probably some other technologies.
> 
> Of course in theory it is possible to build package with two sets 
> of binaries supporting both qt4 and qt5, but I see little
> practical need for that.
> 
> So I propose to add somewhere to devmanual/policies the following 
> recommendation: "If package supports several versions of the same 
> technology (e.g. qt4 and qt5) and more than one is enabled by USE 
> flags, ebuild should prefer the later one (in terms of technology 
> generation).".
> 
> Best regards, Andrew Savchenko
> 
+1
- -- 
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

iQIcBAEBCAAGBQJVvxlqAAoJEAEkDpRQOeFwRqAP/jLkyzsJ0lPind06f8YvQ4aF
Nog8g2pJHJUYXryJwCZpedj4Ju8QWnlE9qOLFO/PvKjNq1AddI7PB/BpUAK1HBuq
9T319lQttGyZAFqEeYm3j1c7IcQInNSXaGLJnLVw19UWgUg1ZuTxiec7XJ7Qovmy
D1BdZrMSVhxzSfCKN0kGM3IDxgInVWnEhPCiqDzDMT/U9j1K1sOFA/77/M+HbEvp
LP26R/ICdznLNTRqAQxBn6TnZ0D6LMp+ngWCvSa07XCyn3O2K1cQA012l3hQ4/Jb
+GP3mk6UM3rhn5saZ+2nJM5axFNylTFcJnqJFjU6//Q7q3C0Xh4sEuu8n3ywgiG4
8Mmta0i9TgGcIjfnCcDpMO6Yvs1g79Hgg3A87tCzJEaYRXWlHjGY+YsoYVIvPS6d
qNdhG8+/8hhQUQy4gcmT7M5HZVkMj/hmju+X9bCPbDrJY6Xii90ZbvCZGiPBAJbm
VebTPg5CAzybhqtYAOiygLKMqh1Sw8LrFlBSAMJpLr89CHN0ODuzQp+Rho6rYcp0
t2J8AWJHW2XJ8TePvDpCDkEog83c1sSxKPqsu8AHTPcw+Bvol4vpmUsv0BQlp9aa
F4ZXxccqTzbZtwJ9x7jBGjlBl6H4Bu0OE/y7nUPG9aTldxMfnEgJeEktUtpAlWCu
fYSYVLjlNUl9OtL/ElnI
=fRV1
-----END PGP SIGNATURE-----

Re: [gentoo-dev] useflag policies

[Ian Stakenvicius]

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

On 03/08/15 03:34 AM, Daniel Campbell (zlg) wrote:
> On 08/02/2015 10:33 AM, Andrew Savchenko wrote:
>> On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote:
>>> Recently some team members of the Qt project have adopted
>>> these ebuild policies: 
>>> https://wiki.gentoo.org/wiki/Project:Qt/Policies
>>> 
>>> I have an issue with the policy adopted under "Requires one of 
>>> two Qt versions". In my opinion, in the case where a package 
>>> offers a choice between qt4 or qt5, we should express this in 
>>> explicit useflags
> 
>> This is what the policy does: "Implement both qt4 and qt5 USE 
>> flags"
> 
>>> and a REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the 
>>> clearest choice.
> 
>> This will create insane amount of blockers if users have both 
>> flags in make.conf (and this is a common scenario).
> 

Why exactly do we need to force-off the use flag for the one that
won't be used, anyways?  Yes, there are qt4 deps in VDB that likely
won't be necessary, which causes --depclean to not necessarily be able
to make -as clean- a system, but realistically this is pretty minor.
Also, i don't see why end-users are going to care; if they specify
USE="qt4 qt5" then they should expect the package to depend on both
sets of the qt deps.

As for the ambiguity of which one the package will use, I think we can
satisfy that the same way we do slots -- that is, the one with the
larger ${PV} (ie qt5) is the one that will be used when both are
available.  Intuitive, simple, and the system "just works".

Are there any cases where things actually break if a package has both
flags enabled? IE, is three a package with IUSE="qt4 qt5" that when
both flags are enabled would build for qt5 only, and happens to be a
dependency atom of something else that needs it to have qt4 support?
That to me is the only case where a REQUIRED_USE needs to be set on a
package.




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

iF4EAREIAAYFAlXA0roACgkQAJxUfCtlWe0CMgD/QDNIoY5Ug2f3+6OwvpIX+KG3
EiF8jm7yhzgoWck4wE8A+wYqFvyKoAedjdNMR6JKfSTuKQLKj0/PoqPu3tqXfkcG
=l8Bx
-----END PGP SIGNATURE-----

Re: [gentoo-dev] useflag policies

[Ben de Groot]

On 4 August 2015 at 22:56, Ian Stakenvicius <axs@gentoo.org> wrote:
> Are there any cases where things actually break if a package has both
> flags enabled? IE, is three a package with IUSE="qt4 qt5" that when
> both flags are enabled would build for qt5 only, and happens to be a
> dependency atom of something else that needs it to have qt4 support?
> That to me is the only case where a REQUIRED_USE needs to be set on a
> package.

I'm not aware we have such a package, but I may be overlooking
something. Either way, I think it is a dangerous road to go down that
way.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] useflag policies

[Ian Stakenvicius]

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

On 05/08/15 02:38 AM, Ben de Groot wrote:
> On 4 August 2015 at 22:56, Ian Stakenvicius <axs@gentoo.org>
> wrote:
>> Are there any cases where things actually break if a package has
>> both flags enabled? IE, is three a package with IUSE="qt4 qt5"
>> that when both flags are enabled would build for qt5 only, and
>> happens to be a dependency atom of something else that needs it
>> to have qt4 support? That to me is the only case where a
>> REQUIRED_USE needs to be set on a package.
> 
> I'm not aware we have such a package, but I may be overlooking 
> something. Either way, I think it is a dangerous road to go down
> that way.
> 

I'm not aware of any either, although I haven't done a comprehensive
audit of the tree to find out.  I would find it unlikely that any such
package exists.

The thing is, we're already travelling that road (have been for a long
while), and IMO there is very little "cost" to travelling this road
compared to the so-called "proper" solution of forcing off one flag or
the other, ESPECIALLY when we are likely to have both flags default-on
soon in the generic desktop profile as was posted earlier.

If we do go the REQUIRED_USE="^^" route on packages, then I think it
would be best that we change the 'desktop' and other profiles s.t.
maintainers need to add their package with whichever flag should be
enabled (qt4 or qt5) to package.use, rather than having the qt*
flag(s) globally enabled in the profile -- otherwise we end up with
end-users having to deal with it.

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

iF4EAREIAAYFAlXCfk4ACgkQAJxUfCtlWe1CswEA0e4c/gRSbjg0b858+uVFc+z2
+05WUPjFsPpfXrdPs3wA/2r0PyitPRoZAWPWBKm8LhMAC5YIHtjhWA7kh2LTImAQ
=gyeU
-----END PGP SIGNATURE-----

[gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Mon, 3 Aug 2015, Ben de Groot wrote:

> Recently some team members of the Qt project have adopted these
> ebuild policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies

> I have an issue with the policy adopted under "Requires one of two
> Qt versions". In my opinion, in the case where a package offers a
> choice between qt4 or qt5, we should express this in explicit
> useflags and a REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user
> the clearest choice.

> Other developers state that users are not interested in such
> implementation details, or that forced choice through REQUIRED_USE
> is too much of a hassle. This results in current ebuilds such as
> quassel to not make it clear that qt4 is an option.

The general policy is outlined here:
https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags

# Note: In order to avoid forcing users to micro-manage flags too
# much, REQUIRED_USE should be used sparingly. Follow the normal
# policy whenever it is possible to do a build that will presumably
# suit the user's needs.

So I think the Qt team's policy (i.e. *no* REQUIRED_USE, prefer qt5 in
case of conflicting flags) is perfectly fine.

> This goes against the principle of least surprise, as well as
> against QA recommendations. I would like to hear specifically from
> QA about how we should proceed, but comments from the wider
> developer community are also welcome.

Maybe output an ewarn message if both qt[45] flags are set, and
therefore the qt5 default is taken?

Ulrich

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

Re: [gentoo-dev] useflag policies

[NP-Hardass]

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

^^ has the pleasant side effect of being easier to read, as a user. The user receives a message saying "at-most-one-of" instead of some convoluted other expression that they don't understand. 

I am all for the use of ^^ add the default for this reason.

Additionally, ?? has the same effect of being easy to understand as the description in the error message is in plain English.

--
NP-Hardass

On August 2, 2015 12:34:51 PM EDT, Ben de Groot <yngwin@gentoo.org> wrote:
>Recently some team members of the Qt project have adopted these ebuild
>policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies
>
>I have an issue with the policy adopted under "Requires one of two Qt
>versions". In my opinion, in the case where a package offers a choice
>between qt4 or qt5, we should express this in explicit useflags and a
>REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest
>choice.
>
>Other developers state that users are not interested in such
>implementation
>details, or that forced choice through REQUIRED_USE is too much of a
>hassle. This results in current ebuilds such as quassel to not make it
>clear that qt4 is an option.
>
>This goes against the principle of least surprise, as well as against
>QA
>recommendations. I would like to hear specifically from QA about how we
>should proceed, but comments from the wider developer community are
>also
>welcome.
>
>-- 
>Cheers,
>
>Ben | yngwin
>Gentoo developer

-- 
NP-Hardass

[-- Attachment #2: Type: text/html, Size: 1885 bytes --]

Re: [gentoo-dev] useflag policies

[Ciaran McCreesh]

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

On Sun, 02 Aug 2015 17:14:47 -0400
NP-Hardass <NP-Hardass@gentoo.org> wrote:
> ^^ has the pleasant side effect of being easier to read, as a user.
> The user receives a message saying "at-most-one-of" instead of some
> convoluted other expression that they don't understand. 
> 
> I am all for the use of ^^ add the default for this reason.
> 
> Additionally, ?? has the same effect of being easy to understand as
> the description in the error message is in plain English.

If you cared about readability, you'd use pkg_pretend.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] useflag policies

[Patrick Lauer]

On Sunday 02 August 2015 22:22:28 Ciaran McCreesh wrote:
> On Sun, 02 Aug 2015 17:14:47 -0400
> 
> NP-Hardass <NP-Hardass@gentoo.org> wrote:
> > ^^ has the pleasant side effect of being easier to read, as a user.
> > The user receives a message saying "at-most-one-of" instead of some
> > convoluted other expression that they don't understand.
> > 
> > I am all for the use of ^^ add the default for this reason.
> > 
> > Additionally, ?? has the same effect of being easy to understand as
> > the description in the error message is in plain English.
> 
> If you cared about readability, you'd use pkg_pretend.

No.

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 03/08/15 07:14, NP-Hardass wrote:
> ^^ has the pleasant side effect of being easier to read, as a user. The
> user receives a message saying "at-most-one-of" instead of some
> convoluted other expression that they don't understand.
> 
> I am all for the use of ^^ add the default for this reason.

This introduces a usability nightmare for anyone with both qt4 and qt5
in their global USE flags (a common configuration).

Re: [gentoo-dev] Re: useflag policies

[James Le Cuirot]

On Mon, 3 Aug 2015 21:23:37 +1000
Michael Palimaka <kensington@gentoo.org> wrote:

> On 03/08/15 07:14, NP-Hardass wrote:
> > ^^ has the pleasant side effect of being easier to read, as a user.
> > The user receives a message saying "at-most-one-of" instead of some
> > convoluted other expression that they don't understand.
> > 
> > I am all for the use of ^^ add the default for this reason.
> 
> This introduces a usability nightmare for anyone with both qt4 and qt5
> in their global USE flags (a common configuration).

What if we had something like this?

REQUIRED_IUSE="^^qt ( qt5 qt4 )"

Users who don't care would set just qt rather than qt4 or qt5 and this
mechanism would automatically enable whichever one appears first in the
brackets. If qt4 or qt5 (or both) are set then the behaviour would
remain as it is now. Or perhaps some variation on this?

I'm not declaring this to be a great idea, just throwing it out there
for consideration. :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] Re: useflag policies

[Dale]

Michael Palimaka wrote:
> On 03/08/15 07:14, NP-Hardass wrote:
>> ^^ has the pleasant side effect of being easier to read, as a user. The
>> user receives a message saying "at-most-one-of" instead of some
>> convoluted other expression that they don't understand.
>>
>> I am all for the use of ^^ add the default for this reason.
> This introduces a usability nightmare for anyone with both qt4 and qt5
> in their global USE flags (a common configuration).
>
>
>


As a Gentoo user.  This is what I have set and what I hope to get
because of the settings.  I have both qt4 and qt5 set in make.conf for
my USE flags.  I expect qt5 for whatever packages can work with qt5 and
qt4 for whatever isn't ready for qt5 but requires qt.  If for some
reason a package isn't quite ready for qt5 and won't function correctly
for me, I can always set that in package.use until it is.  My current
entries for this:

media-libs/phonon-vlc qt5
media-video/mkvtoolnix -qt5

I don't have notes on that so not sure what was ran into to require
those.  I may comment those out and give them another try. 

Point of this post, provide a little user info about expectations and
settings.  Y'all sort out the best way forward and let us know if we
need to change something.  :-) 

Dale

:-)  :-) 

Re: [gentoo-dev] Re: useflag policies

[Alan McKinnon]

On 03/08/2015 15:07, Dale wrote:
> Michael Palimaka wrote:
>> On 03/08/15 07:14, NP-Hardass wrote:
>>> ^^ has the pleasant side effect of being easier to read, as a user. The
>>> user receives a message saying "at-most-one-of" instead of some
>>> convoluted other expression that they don't understand.
>>>
>>> I am all for the use of ^^ add the default for this reason.
>> This introduces a usability nightmare for anyone with both qt4 and qt5
>> in their global USE flags (a common configuration).
>>
>>
>>
> 
> 
> As a Gentoo user.  This is what I have set and what I hope to get
> because of the settings.  I have both qt4 and qt5 set in make.conf for
> my USE flags.  I expect qt5 for whatever packages can work with qt5 and
> qt4 for whatever isn't ready for qt5 but requires qt.  If for some
> reason a package isn't quite ready for qt5 and won't function correctly
> for me, I can always set that in package.use until it is.  My current
> entries for this:
> 
> media-libs/phonon-vlc qt5
> media-video/mkvtoolnix -qt5
> 
> I don't have notes on that so not sure what was ran into to require
> those.  I may comment those out and give them another try. 
> 
> Point of this post, provide a little user info about expectations and
> settings.  Y'all sort out the best way forward and let us know if we
> need to change something.  :-) 


Dale and I think alike.

I also have Qt4 and Qt5 installed, and I expect packages that use them
to link to the version that works better (understanding that "better" is
usually the opinion of upstream and the devs). If I decide I care about
which one works better for a given package, then I'm happy to
package.use but mostly I like that file to be as empty as I can get it.

What I don't want is for the machinery to give the impression that I
can't just go with whatever the dev put in the ebuild for the general
case. I also don't want to have to keep going back to use.desc because
it's not obvious what the flag probably does.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] useflag policies

[Patrick Lauer]

On Monday 03 August 2015 00:34:51 Ben de Groot wrote:
> Recently some team members of the Qt project have adopted these ebuild
> policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies
> 
> I have an issue with the policy adopted under "Requires one of two Qt
> versions". In my opinion, in the case where a package offers a choice
> between qt4 or qt5, we should express this in explicit useflags and a
> REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice.

Since qt4 and qt5 are both relatively 'heavy' dependencies and quite different 
in many ways (including differences in default styles) many users will want to 
stick with only one of those.

The gtk 'solution' forced some ugly things like masking gtk+:3, gconf:3, ... 
and then selecting packages based on specific -r200 / -r300 revisions. So much 
work to avoid regressing into gtk3!

(Which is especially frustrating because *dbus* has wrong dependencies just so 
that gtk/gnome apps using dconf can save config ... )
> 
> Other developers state that users are not interested in such implementation
> details, or that forced choice through REQUIRED_USE is too much of a
> hassle. This results in current ebuilds such as quassel to not make it
> clear that qt4 is an option.

I find setting USE="qt4 -qt5" a lot more obvious than having USE="qt" (why not 
USE="X" ?) which then does different things based on another useflag, 
sometimes. Maybe. It's horribly inconsistent and even might change result over 
time, which is not very user-friendly.
> 
> This goes against the principle of least surprise, as well as against QA
> recommendations. I would like to hear specifically from QA about how we
> should proceed, but comments from the wider developer community are also
> welcome.

I would prefer having qt4 and qt5 useflags independent, and no generic qt 
useflag.

Re: [gentoo-dev] useflag policies

[Rich Freeman]

On Sun, Aug 2, 2015 at 9:03 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> I find setting USE="qt4 -qt5" a lot more obvious than having USE="qt" (why not
> USE="X" ?) which then does different things based on another useflag,
> sometimes. Maybe. It's horribly inconsistent and even might change result over
> time, which is not very user-friendly.

The problem is that this approach breaks down with scenarios which are
likely to be commonplace.

I want to use fooplayer and bargrapher which are two qt-based
applications.  fooplayer only supports qt4, and bargrapher only
supports qt5.  What USE flags should I set, without restorting to
per-package flags?  Then I also install klunkybrowser which supports
both qt4 and qt5 but not at the same time, so how should I manage my
flags for that?

The current qt policy just has each package support only one version
using USE=qt and while it denies user choice for klunkybrowser it is
at least simple.  The alternative of "qt means I don't care what
version" is also simple - the klunkybrowser maintainer would pick the
best default and those who care can override it.  The approach qt4=qt4
and qt5=qt5 seems simpler on the surface, but it means that users end
up having to set tons of per-package configurations when they don't
actually care which one they use, and it also doesn't necessarily hint
to users which will give them the best experience on each package.

Right now you can get away with just USE="qt4 -qt5" because we don't
have many qt5-only packages in the tree (I actually have one I've been
holding off on introducing due to qt5 not being in the tree until
recently).  When that changes the mutually-exclusive flags approach
will be very painful.

--
Rich

Re: [gentoo-dev] useflag policies

[Ben de Groot]

On 3 August 2015 at 09:37, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Aug 2, 2015 at 9:03 PM, Patrick Lauer <patrick@gentoo.org> wrote:
>> I find setting USE="qt4 -qt5" a lot more obvious than having USE="qt" (why not
>> USE="X" ?) which then does different things based on another useflag,
>> sometimes. Maybe. It's horribly inconsistent and even might change result over
>> time, which is not very user-friendly.
>
> The problem is that this approach breaks down with scenarios which are
> likely to be commonplace.
>
> I want to use fooplayer and bargrapher which are two qt-based
> applications.  fooplayer only supports qt4, and bargrapher only
> supports qt5.  What USE flags should I set, without restorting to
> per-package flags?

These packages would not have useflags, as they only use one toolkit.

>  Then I also install klunkybrowser which supports
> both qt4 and qt5 but not at the same time, so how should I manage my
> flags for that?

Set your global default in make.conf as either qt4 or qt5. If you want
to deviate from that for some package, you can set per package use
flags. Easy peasy. Clear and straightforward. Principle of least
surprise.

> The current qt policy just has each package support only one version
> using USE=qt

No, that is not at all the case. We have banned a simple qt useflag
since many years (which is also the QA policy). We have been using
versioned qt3, qt4, qt5 useflags.

> and while it denies user choice for klunkybrowser it is
> at least simple.  The alternative of "qt means I don't care what
> version" is also simple

Except many users do care. I don't see the benefit in changing the way
we used to do this.

> The approach qt4=qt4
> and qt5=qt5 seems simpler on the surface, but it means that users end
> up having to set tons of per-package configurations when they don't
> actually care which one they use, and it also doesn't necessarily hint
> to users which will give them the best experience on each package.

If they don't care, they can simply follow the defaults and not set
any qt4 or qt5 useflags in make.conf.

> Right now you can get away with just USE="qt4 -qt5" because we don't
> have many qt5-only packages in the tree

As I said before, this is of no consequence, as there would be no
mutually exclusive qt4 and qt5 useflags anyway for those packages.

The problem only appears with packages that force a choice between qt4
and qt5, and users that have enabled both useflags globally.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] useflag policies

[Rich Freeman]

On Sun, Aug 2, 2015 at 11:24 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>> I want to use fooplayer and bargrapher which are two qt-based
>> applications.  fooplayer only supports qt4, and bargrapher only
>> supports qt5.  What USE flags should I set, without restorting to
>> per-package flags?
>
> These packages would not have useflags, as they only use one toolkit.
>

What if qt support is optional, and I do/don't want it enabled?

-- 
Rich

Re: [gentoo-dev] useflag policies

[Ben de Groot]

On 3 August 2015 at 11:30, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Aug 2, 2015 at 11:24 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>>> I want to use fooplayer and bargrapher which are two qt-based
>>> applications.  fooplayer only supports qt4, and bargrapher only
>>> supports qt5.  What USE flags should I set, without restorting to
>>> per-package flags?
>>
>> These packages would not have useflags, as they only use one toolkit.
>>
>
> What if qt support is optional, and I do/don't want it enabled?

Users who don't care, simply follow the defaults as set by the package
maintainer or profile. Users who do care wouldn't mind adding a rule
to their package.use.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] useflag policies

[Maciej Mrozowski]

On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote:
|  The approach qt4=qt4
| and qt5=qt5 seems simpler on the surface, but it means that users end
| up having to set tons of per-package configurations when they don't
| actually care which one they use,

I will risk a thesis that if they didn't care, they wouldn't have chosen 
Gentoo...

regards
MM

Re: [gentoo-dev] useflag policies

[Dale]

Maciej Mrozowski wrote:
> On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote:
> |  The approach qt4=qt4
> | and qt5=qt5 seems simpler on the surface, but it means that users end
> | up having to set tons of per-package configurations when they don't
> | actually care which one they use,
>
> I will risk a thesis that if they didn't care, they wouldn't have chosen 
> Gentoo...
>
> regards
> MM
>
>

You may lose that one if I'm seeing your point correctly.  See Alan and
my earlier replies.  I have both qt4 and qt5 set and I leave which is
best to use to the devs to control in the ebuild.  If for example qt5
does not work well for a package, let the ebuild pick qt4 for that
package.  If qt5 works reliably, then build with qt5.  If I have a
problem with it, then I can set it in package.use if needed, doesn't
build or function correctly or I want qt5 even if it isn't stable.  As
things switch to qt5 more, I don't have to do anything except let the
updates roll out as they become stable and the dev sets that in the
ebuild. 

Keep in mind, devs already do a LOT of the selection process. 
Otherwise, we could set any and every USE flag and package combination
there is without any restrictions.  In other words, we could have USE
flag soup even if it is known that two or more USE flags clash.  As it
is, if a dev knows two flags clash, we get a nifty error message and
then we get to figure out how to get it to work right, sometimes
portage's error message is cryptic to say the least. 

If I took your point wrong, my apologies.

Lowly user.

Dale

:-)  :-) 

Re: [gentoo-dev] useflag policies

[Rich Freeman]

On Mon, Aug 3, 2015 at 3:07 PM, Maciej Mrozowski <reavertm@gmail.com> wrote:
> On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote:
> |  The approach qt4=qt4
> | and qt5=qt5 seems simpler on the surface, but it means that users end
> | up having to set tons of per-package configurations when they don't
> | actually care which one they use,
>
> I will risk a thesis that if they didn't care, they wouldn't have chosen
> Gentoo...
>

Obviously there are many reasons people use Gentoo, but here is my
perspective on this.

The value of Gentoo is that it gives you a LOT of power to tweak
individual package configurations, without the requirement to do this
for everything.  There are packages that I carefully configure USE
flags for, CFLAGS for, epatch_user, and so on.  Heck, some packages I
run in containers where I can carefully control almost all aspects of
their environment.  Then on the same host I'll have screen and bash
and a million other packages installed where exact configuration is
not critical, and so I want it to "just work."  If I wanted to
micromanage everything I might as well run Linux From Scratch.

Gentoo should be the best of both worlds.  We should give users the
power to tweak things, but we shouldn't force them to play with config
files all day long just to have a functional system.  If users want to
care we let them care instead of telling them "don't touch" like most
other distros, but if they don't care we still provide reasonable
defaults.

-- 
Rich

Re: [gentoo-dev] useflag policies

[Alan McKinnon]

On 03/08/2015 22:20, Rich Freeman wrote:
> On Mon, Aug 3, 2015 at 3:07 PM, Maciej Mrozowski <reavertm@gmail.com> wrote:
>> On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote:
>> |  The approach qt4=qt4
>> | and qt5=qt5 seems simpler on the surface, but it means that users end
>> | up having to set tons of per-package configurations when they don't
>> | actually care which one they use,
>>
>> I will risk a thesis that if they didn't care, they wouldn't have chosen
>> Gentoo...
>>
> 
> Obviously there are many reasons people use Gentoo, but here is my
> perspective on this.
> 
> The value of Gentoo is that it gives you a LOT of power to tweak
> individual package configurations, without the requirement to do this
> for everything.  There are packages that I carefully configure USE
> flags for, CFLAGS for, epatch_user, and so on.  Heck, some packages I
> run in containers where I can carefully control almost all aspects of
> their environment.  Then on the same host I'll have screen and bash
> and a million other packages installed where exact configuration is
> not critical, and so I want it to "just work."  If I wanted to
> micromanage everything I might as well run Linux From Scratch.
> 
> Gentoo should be the best of both worlds.  We should give users the
> power to tweak things, but we shouldn't force them to play with config
> files all day long just to have a functional system.  If users want to
> care we let them care instead of telling them "don't touch" like most
> other distros, but if they don't care we still provide reasonable
> defaults.
> 

+1

One of the most powerful aspects of ebuilds is the ability to not have
to control something the user does not want to. I use Gentoo because I
can control what I wish and like Rich the bits I want to control are a
small fraction of the whole.

When a dev says "I will risk a thesis that if they didn't care, they
wouldn't have chosen Gentoo", there is a place for that but it is by no
means the general case. We DO accommodate the control freaks, we let
them USE="-*" and let them keep all the tiny shards.

But the truth is far more subtle than a care-all/care-none scenario.

I say stick with reasonable defaults, and for better or worse, that
includes "use highest version in ACCEPT_KEYWORDS unless user says otherwise"


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] useflag policies

[Ben de Groot]

On 4 August 2015 at 04:20, Rich Freeman <rich0@gentoo.org> wrote:
> [...]
> Gentoo should be the best of both worlds.  We should give users the
> power to tweak things, but we shouldn't force them to play with config
> files all day long just to have a functional system.  If users want to
> care we let them care instead of telling them "don't touch" like most
> other distros, but if they don't care we still provide reasonable
> defaults.

And that is exactly what we do. The kde profile enables qt4, the
plasma profile enables qt5, the other profiles have no qt* useflags
enabled. These are reasonable defaults.

Of course some users will proceed to enable both qt4 and qt5 globally
in their make.conf, but I don't think it is unreasonable to expect
them to then deal with adding exceptions to package.use for those
packages where exactly-one-of is required.

In my opinion, this is the way Gentoo has always worked, and we should
simply recommend users to only set one of the qt* useflags as globally
enabled, if they want to prevent such micro-management. Hiding the qt4
option is in my opinion the wrong solution around people complaining
after they have consciously enabled both flags.

If this is not acceptable (or "absolutely unusable" as one dev put
it), then we need a proper solution, which a) will not hide the qt4
option, and b) will prevent triggering required_use blockage by
choosing qt5 over qt4 in case both are enabled, while c) informing the
user about this. This probably requires new eclass or even EAPI
functionality.

In the meantime, we should stick with the policies adopted at the qt3
to qt4 transition (explicit versioned useflags) and let the user deal
with per-package management if they enable both flags.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] useflag policies

[Alexandre Rostovtsev]

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

On Tue, 2015-08-04 at 11:59 +0800, Ben de Groot wrote:
> On 4 August 2015 at 04:20, Rich Freeman <rich0@gentoo.org> wrote:
> > [...]
> > Gentoo should be the best of both worlds.  We should give users the
> > power to tweak things, but we shouldn't force them to play with config
> > files all day long just to have a functional system.  If users want to
> > care we let them care instead of telling them "don't touch" like most
> > other distros, but if they don't care we still provide reasonable
> > defaults.
> 
> And that is exactly what we do. The kde profile enables qt4, the
> plasma profile enables qt5, the other profiles have no qt* useflags
> enabled. These are reasonable defaults.

That is not correct. The desktop profile enables qt4, because it is a
reasonable default (for qt-only packages, USE=-qt4 means "don't build
any gui", but desktop users always expect some kind of a gui by
default, whether it's gtk or qt*.)

The result is that qt4 is enabled in child profiles of desktop - gnome
and kde and plasma. Since plasma enables qt5 and does nothing with qt4,
you have all qt versions enabled there.

And when popular qt5-only, gui-optional packages appear in the tree, we
will need to enable qt5 in desktop profile too.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] useflag policies

[Davide Pesavento]

On Mon, Aug 3, 2015 at 10:10 PM, Alexandre Rostovtsev
<tetromino@gentoo.org> wrote:
> On Tue, 2015-08-04 at 11:59 +0800, Ben de Groot wrote:
>> On 4 August 2015 at 04:20, Rich Freeman <rich0@gentoo.org> wrote:
>> > [...]
>> > Gentoo should be the best of both worlds.  We should give users the
>> > power to tweak things, but we shouldn't force them to play with config
>> > files all day long just to have a functional system.  If users want to
>> > care we let them care instead of telling them "don't touch" like most
>> > other distros, but if they don't care we still provide reasonable
>> > defaults.
>>
>> And that is exactly what we do. The kde profile enables qt4, the
>> plasma profile enables qt5, the other profiles have no qt* useflags
>> enabled. These are reasonable defaults.
>
> That is not correct. The desktop profile enables qt4, because it is a
> reasonable default (for qt-only packages, USE=-qt4 means "don't build
> any gui", but desktop users always expect some kind of a gui by
> default, whether it's gtk or qt*.)
>
> The result is that qt4 is enabled in child profiles of desktop - gnome
> and kde and plasma. Since plasma enables qt5 and does nothing with qt4,
> you have all qt versions enabled there.
>
> And when popular qt5-only, gui-optional packages appear in the tree, we
> will need to enable qt5 in desktop profile too.

Exactly, +1.

[gentoo-dev] Re: useflag policies

[Duncan]

Ben de Groot posted on Tue, 04 Aug 2015 11:59:40 +0800 as excerpted:

> In my opinion, this is the way Gentoo has always worked, and we should
> simply recommend users to only set one of the qt* useflags as globally
> enabled, if they want to prevent such micro-management. Hiding the qt4
> option is in my opinion the wrong solution around people complaining
> after they have consciously enabled both flags.
> 
> If this is not acceptable (or "absolutely unusable" as one dev put it),
> then we need a proper solution, which a) will not hide the qt4 option,
> and b) will prevent triggering required_use blockage by choosing qt5
> over qt4 in case both are enabled, while c) informing the user about
> this. This probably requires new eclass or even EAPI functionality.

What about a solution such as that used by python, USE=qt, for turning on 
qt support at all if it's optional, with QT_TARGETS for people to set to 
the versions they want if more than one can be enabled at once, and 
QT_SINGLE_TARGET for people to set to their preferred if a package can 
build against only one at a time, but that one can be chosen?

And of course, just as with python, people can setup an /etc/portage/env/
* file for exceptions, and point as many packages at that file as desired 
using package.env.[1]

But this would be dramatically simpler with qt than it is with python, 
since there will normally only be two (with a theoretical but unlikely 
possibility of three) choices at the same time, and the time between qt 
slot upgrades and slot-effective times as well is much /much/ longer than 
between python slot upgrades.

Of course it'd require a whole new set of eclasses, but it's not as if 
that hasn't been done before.

[1] FWIW, that's the python solution I've been using for awhile, with 
PYTHON_SINGLE_TARGET set to 3.3 and then 3.4 in make.conf, with an
/etc/portage/env/python.starget.27 file that does what the name suggests, 
and formerly quite a few package entries in /etc/portage/package.env 
pointing to it that couldn't handle python3 yet, but now only one, app-
text/asciidoc.

-- 
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] useflag policies

[Davide Pesavento]

On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 4 August 2015 at 04:20, Rich Freeman <rich0@gentoo.org> wrote:
>> [...]
>> Gentoo should be the best of both worlds.  We should give users the
>> power to tweak things, but we shouldn't force them to play with config
>> files all day long just to have a functional system.  If users want to
>> care we let them care instead of telling them "don't touch" like most
>> other distros, but if they don't care we still provide reasonable
>> defaults.
>
> And that is exactly what we do. The kde profile enables qt4, the
> plasma profile enables qt5, the other profiles have no qt* useflags
> enabled. These are reasonable defaults.
>

As tetromino pointed out, this is very far from the real current situation.

> Of course some users will proceed to enable both qt4 and qt5 globally
> in their make.conf, but I don't think it is unreasonable to expect
> them to then deal with adding exceptions to package.use for those
> packages where exactly-one-of is required.
>
> In my opinion, this is the way Gentoo has always worked, and we should
> simply recommend users to only set one of the qt* useflags as globally
> enabled, if they want to prevent such micro-management. Hiding the qt4
> option is in my opinion the wrong solution around people complaining
> after they have consciously enabled both flags.
>
> If this is not acceptable (or "absolutely unusable" as one dev put
> it), then we need a proper solution, which a) will not hide the qt4
> option, and b) will prevent triggering required_use blockage by
> choosing qt5 over qt4 in case both are enabled, while c) informing the
> user about this. This probably requires new eclass or even EAPI
> functionality.
>

Please go ahead and design and implement such functionality (a sort of
REQUIRED_USE defaults). In the meantime, we will apply the policies
written in the Qt project wiki page.

> In the meantime, we should stick with the policies adopted at the qt3
> to qt4 transition (explicit versioned useflags) and let the user deal
> with per-package management if they enable both flags.
>

We didn't have REQUIRED_USE at the time of the qt3->qt4 transition, so
this point is completely moot.

Re: [gentoo-dev] useflag policies

[Ben de Groot]

On 5 August 2015 at 03:09, Davide Pesavento <pesa@gentoo.org> wrote:
> On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 4 August 2015 at 04:20, Rich Freeman <rich0@gentoo.org> wrote:
>>> [...]
>>> Gentoo should be the best of both worlds.  We should give users the
>>> power to tweak things, but we shouldn't force them to play with config
>>> files all day long just to have a functional system.  If users want to
>>> care we let them care instead of telling them "don't touch" like most
>>> other distros, but if they don't care we still provide reasonable
>>> defaults.
>>
>> And that is exactly what we do. The kde profile enables qt4, the
>> plasma profile enables qt5, the other profiles have no qt* useflags
>> enabled. These are reasonable defaults.
>>
>
> As tetromino pointed out, this is very far from the real current situation.

Indeed, I was wrong here. We will need another solution.

>> Of course some users will proceed to enable both qt4 and qt5 globally
>> in their make.conf, but I don't think it is unreasonable to expect
>> them to then deal with adding exceptions to package.use for those
>> packages where exactly-one-of is required.
>>
>> In my opinion, this is the way Gentoo has always worked, and we should
>> simply recommend users to only set one of the qt* useflags as globally
>> enabled, if they want to prevent such micro-management. Hiding the qt4
>> option is in my opinion the wrong solution around people complaining
>> after they have consciously enabled both flags.
>>
>> If this is not acceptable (or "absolutely unusable" as one dev put
>> it), then we need a proper solution, which a) will not hide the qt4
>> option, and b) will prevent triggering required_use blockage by
>> choosing qt5 over qt4 in case both are enabled, while c) informing the
>> user about this. This probably requires new eclass or even EAPI
>> functionality.
>>
>
> Please go ahead and design and implement such functionality (a sort of
> REQUIRED_USE defaults).

Something along the lines of PYTHON_TARGETS could work. But
personally, I'm happy with REQUIRED_USE.

> In the meantime, we will apply the policies
> written in the Qt project wiki page.

Except for the one that is wrong.

>> In the meantime, we should stick with the policies adopted at the qt3
>> to qt4 transition (explicit versioned useflags) and let the user deal
>> with per-package management if they enable both flags.
>>
>
> We didn't have REQUIRED_USE at the time of the qt3->qt4 transition, so
> this point is completely moot.

We had something worse. That didn't prevent us from using it tho.

-- 
Cheers,

Ben | yngwin
Gentoo developer

[gentoo-dev] Re: useflag policies

[Sergey Popov]

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

<qa team lead hat>

In short - apropriate REQUIRED_USE with setting recommended
USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")

</qa team lead hat>

That's most painless decision for both developers and users. Developers
do not need to maintain ugly dependencies like

DEPEND="qt4 ? (
qt5 ( dev-qt/qtcore:5 )
!qt5 ( dev-qt/qtcore:4 )
)
...
"
and other mess.

</qa team lead hat>

Users will have default behaviour for empty make.conf. If they adjust
they make.conf to globally include/exclude some Qt-related USEs - they
are already moving from default and that's why - they can add apropriate
options to package.use


02.08.2015 19:34, Ben de Groot пишет:
> Recently some team members of the Qt project have adopted these ebuild
> policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies
> 
> I have an issue with the policy adopted under "Requires one of two Qt
> versions". In my opinion, in the case where a package offers a choice
> between qt4 or qt5, we should express this in explicit useflags and a
> REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice.
> 
> Other developers state that users are not interested in such
> implementation details, or that forced choice through REQUIRED_USE is
> too much of a hassle. This results in current ebuilds such as quassel to
> not make it clear that qt4 is an option.
> 
> This goes against the principle of least surprise, as well as against QA
> recommendations. I would like to hear specifically from QA about how we
> should proceed, but comments from the wider developer community are also
> welcome.
> 
> -- 
> Cheers,
> 
> Ben | yngwin
> Gentoo developer
> 


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Alexandre Rostovtsev]

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

On Sun, 2015-08-09 at 22:38 +0300, Sergey Popov wrote:
> <qa team lead hat>
> 
> In short - apropriate REQUIRED_USE with setting recommended
> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
> 
> </qa team lead hat>

If a package has optional guis, why should users of the default profile get any
gui enabled by default? The default profile usually means "headless server". It
means users who specifically don't need gtk, don't need qt4, don't need qt5,
don't need X.

So please don't + desktop-oriented USE flags in an ebuild's IUSE by default
unless the whole ebuild is intended mainly for desktop users.

> Users will have default behaviour for empty make.conf. If they adjust
> they make.conf to globally include/exclude some Qt-related USEs - they
> are already moving from default and that's why - they can add apropriate
> options to package.use

There is more than one "default" from which to move away. Different profiles
globally enable different flags. Desktop, gnome, and kde profiles already enable
qt4 globally. Plasma already enables qt4 and qt5 globally. And the desktop
profile will probably end up enabling qt4 and qt5 at some point.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

What's not clear with 'apropriate' word in my sentence?

Let me clarify - if package depend either on Qt4 or Qt5 and CAN not be
built with Qt at all - force this behaviour with REQUIRED_USE.

I think that it was obvious that i have meant exactly this case, cause
other cases are unreasonable here.

09.08.2015 23:07, Alexandre Rostovtsev пишет:
> On Sun, 2015-08-09 at 22:38 +0300, Sergey Popov wrote:
>> <qa team lead hat>
>>
>> In short - apropriate REQUIRED_USE with setting recommended
>> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
>>
>> </qa team lead hat>
> 
> If a package has optional guis, why should users of the default profile get any
> gui enabled by default? The default profile usually means "headless server". It
> means users who specifically don't need gtk, don't need qt4, don't need qt5,
> don't need X.
> 
> So please don't + desktop-oriented USE flags in an ebuild's IUSE by default
> unless the whole ebuild is intended mainly for desktop users.
> 
>> Users will have default behaviour for empty make.conf. If they adjust
>> they make.conf to globally include/exclude some Qt-related USEs - they
>> are already moving from default and that's why - they can add apropriate
>> options to package.use
> 
> There is more than one "default" from which to move away. Different profiles
> globally enable different flags. Desktop, gnome, and kde profiles already enable
> qt4 globally. Plasma already enables qt4 and qt5 globally. And the desktop
> profile will probably end up enabling qt4 and qt5 at some point.
> 


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Davide Pesavento]

On Sun, Aug 9, 2015 at 12:38 PM, Sergey Popov <pinkbyte@gentoo.org> wrote:
> <qa team lead hat>
>
> In short - apropriate REQUIRED_USE with setting recommended
> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
>
> </qa team lead hat>
>
> That's most painless decision for both developers and users. Developers
> do not need to maintain ugly dependencies like
>
> DEPEND="qt4 ? (
> qt5 ( dev-qt/qtcore:5 )
> !qt5 ( dev-qt/qtcore:4 )
> )
> ...
> "
> and other mess.
>
> </qa team lead hat>
>
> Users will have default behaviour for empty make.conf. If they adjust
> they make.conf to globally include/exclude some Qt-related USEs - they
> are already moving from default and that's why - they can add apropriate
> options to package.use
>

Sergey,

It seems you completely ignored the discussion that took place in this
thread (and I also think you misunderstood the scenario judging from
the example you gave). Therefore I'm sorry but I will ignore your
opinion as QA team lead.

Thanks,
Davide

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

Err, i have read the whole thread and still does not get a point, why i
am wrong.

It's old battle like we have beforce with "gtk" meaning "any versions of
GTK flag". This behaviour should be killed with fire.

Let's me reiterate some of the cases:

1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
be chosen, but not both.

Fix this with REQUIRED_USE, do not enable any of Qt flags by default

2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
required, but not both

Same thing here, different REQUIRED_USE operator. But - enable one of
the flags by default to ease life of users.

3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
package even exists?)

Do not use REQUIRED_USE here, not needed.

Now, please tell me, where am i wrong?

09.08.2015 23:08, Davide Pesavento пишет:
> On Sun, Aug 9, 2015 at 12:38 PM, Sergey Popov <pinkbyte@gentoo.org> wrote:
>> <qa team lead hat>
>>
>> In short - apropriate REQUIRED_USE with setting recommended
>> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
>>
>> </qa team lead hat>
>>
>> That's most painless decision for both developers and users. Developers
>> do not need to maintain ugly dependencies like
>>
>> DEPEND="qt4 ? (
>> qt5 ( dev-qt/qtcore:5 )
>> !qt5 ( dev-qt/qtcore:4 )
>> )
>> ...
>> "
>> and other mess.
>>
>> </qa team lead hat>
>>
>> Users will have default behaviour for empty make.conf. If they adjust
>> they make.conf to globally include/exclude some Qt-related USEs - they
>> are already moving from default and that's why - they can add apropriate
>> options to package.use
>>
> 
> Sergey,
> 
> It seems you completely ignored the discussion that took place in this
> thread (and I also think you misunderstood the scenario judging from
> the example you gave). Therefore I'm sorry but I will ignore your
> opinion as QA team lead.
> 
> Thanks,
> Davide
> 

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Georg Rudoy]

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

2015-08-11 11:10 GMT+01:00 Sergey Popov <pinkbyte@gentoo.org>:
>
> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
> package even exists?)
>

Take app-text/poppler as an "officially supported" example.

Take x11-libs/qwt as an example of a library that gets a patched library
name to avoid collisions (at least, last time I looked into it).

I would argue this is a very desirably property for libraries in general. I
even keep my own small overlay with Qt5-enabled versions of libraries like
qxmpp, qtermwidget or liblastfm.


> Do not use REQUIRED_USE here, not needed.
>

You missed the fourth option: the package can not be built without Qt GUI,
but it supports building with either Qt version at the same time.

-- 
  Georg Rudoy

[-- Attachment #2: Type: text/html, Size: 1334 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 13:18, Georg Rudoy пишет:
> 
> You missed the fourth option: the package can not be built without Qt
> GUI, but it supports building with either Qt version at the same time.
> 

Not a problem.

REQUIRED_USE="|| ( qt4 qt5 )"

At least one of flags should be enabled, but both can be enabled too(if
i understand your example correctly)

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 11/08/15 20:10, Sergey Popov wrote:
> Err, i have read the whole thread and still does not get a point, why i
> am wrong.

You clearly have not. The reasoning behind Qt team's policy is described
on the page and has been reiterated on this list. You are undermining
what little confidence there is in the QA team by making decisions with
no consultation about problems you do not understand.

> It's old battle like we have beforce with "gtk" meaning "any versions of
> GTK flag". This behaviour should be killed with fire.
> 
> Let's me reiterate some of the cases:
> 
> 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
> be chosen, but not both.
> 
> Fix this with REQUIRED_USE, do not enable any of Qt flags by default

Problem: this requires manual intervention if the user has both qt4 and
qt5 USE flags enabled.

> 
> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
> required, but not both
> 
> Same thing here, different REQUIRED_USE operator. But - enable one of
> the flags by default to ease life of users.

Problem: this requires manual intervention if the user has both qt4 and
qt5 USE flags enabled.

> 
> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
> package even exists?)
> 
> Do not use REQUIRED_USE here, not needed.
> 
> Now, please tell me, where am i wrong?
> 

The problem is manual intervention is required if the user has both qt4
and qt5 USE flags enabled - and this is a common configuration. It is
not acceptable to make a user manually add numerous package.use entries
when all they want to do is install KDE.

I agree Qt's policy is not a perfect solution, but in the absence of
some feature allowing a preference to be set when there is a conflict
it's the best we've got.

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 15:30, Michael Palimaka пишет:
> On 11/08/15 20:10, Sergey Popov wrote:
>> Err, i have read the whole thread and still does not get a point, why i
>> am wrong.
> 
> You clearly have not. The reasoning behind Qt team's policy is described
> on the page and has been reiterated on this list. You are undermining
> what little confidence there is in the QA team by making decisions with
> no consultation about problems you do not understand.
> 
>> It's old battle like we have beforce with "gtk" meaning "any versions of
>> GTK flag". This behaviour should be killed with fire.
>>
>> Let's me reiterate some of the cases:
>>
>> 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
>> be chosen, but not both.
>>
>> Fix this with REQUIRED_USE, do not enable any of Qt flags by default
> 
> Problem: this requires manual intervention if the user has both qt4 and
> qt5 USE flags enabled.
>

User choice of using USE flags is NOT a problem

>>
>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
>> required, but not both
>>
>> Same thing here, different REQUIRED_USE operator. But - enable one of
>> the flags by default to ease life of users.
> 
> Problem: this requires manual intervention if the user has both qt4 and
> qt5 USE flags enabled.

Same here

>>
>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
>> package even exists?)
>>
>> Do not use REQUIRED_USE here, not needed.
>>
>> Now, please tell me, where am i wrong?
>>
> 
> The problem is manual intervention is required if the user has both qt4
> and qt5 USE flags enabled - and this is a common configuration. It is
> not acceptable to make a user manually add numerous package.use entries
> when all they want to do is install KDE.

And here

> I agree Qt's policy is not a perfect solution, but in the absence of
> some feature allowing a preference to be set when there is a conflict
> it's the best we've got.
> 

If you want to go this way, then please provide helper functions in
eclasses to set dependencies properly for all common use cases. That
will ease life both of developers and users.

Leaving constructing of dependencies to developers in all cases will
cause only pain in your solution.

Look at the example with berkdb/gdbm, that i have posted recently.

If both of flags are not set - we stick to default.
Should this be set in EVERY ebuild explicitly?

Maybe provide some sugar like $(qt_use_default qtgui 5), where
qt_use_default is the name of function, qtgui is the package and 5 is
the slot for default choice, where either BOTH of flags(qt4, qt5) are
enabled or disabled

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[James Le Cuirot]

On Tue, 11 Aug 2015 15:58:49 +0300
Sergey Popov <pinkbyte@gentoo.org> wrote:

> If both of flags are not set - we stick to default.
> Should this be set in EVERY ebuild explicitly?
> 
> Maybe provide some sugar like $(qt_use_default qtgui 5), where
> qt_use_default is the name of function, qtgui is the package and 5 is
> the slot for default choice, where either BOTH of flags(qt4, qt5) are
> enabled or disabled

That sounds a little bit like what I suggested earlier.

https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 16:11, James Le Cuirot пишет:
> On Tue, 11 Aug 2015 15:58:49 +0300
> Sergey Popov <pinkbyte@gentoo.org> wrote:
> 
>> If both of flags are not set - we stick to default.
>> Should this be set in EVERY ebuild explicitly?
>>
>> Maybe provide some sugar like $(qt_use_default qtgui 5), where
>> qt_use_default is the name of function, qtgui is the package and 5 is
>> the slot for default choice, where either BOTH of flags(qt4, qt5) are
>> enabled or disabled
> 
> That sounds a little bit like what I suggested earlier.
> 
> https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df
> 

But without introducing brand new useless USE flag. Which makes huge
difference to me :-)

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Rich Freeman]

On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
> 11.08.2015 16:11, James Le Cuirot пишет:
>> On Tue, 11 Aug 2015 15:58:49 +0300
>> Sergey Popov <pinkbyte@gentoo.org> wrote:
>>
>>> If both of flags are not set - we stick to default.
>>> Should this be set in EVERY ebuild explicitly?
>>>
>>> Maybe provide some sugar like $(qt_use_default qtgui 5), where
>>> qt_use_default is the name of function, qtgui is the package and 5 is
>>> the slot for default choice, where either BOTH of flags(qt4, qt5) are
>>> enabled or disabled
>>
>> That sounds a little bit like what I suggested earlier.
>>
>> https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df
>>
>
> But without introducing brand new useless USE flag. Which makes huge
> difference to me :-)
>

If we want the typical user to not set either qt4 or qt5, are we
saying that any package that could use either always enable one of
them by default?  Then all users get a GUI by default, and then users
have to explicitly disable it?  That seems to be the opposite of how
we normally do things, but it does let you get away from having lots
of users turning on qt.

Normally we'd just turn them on in a profile, but you can't do this if
some packages need qt4, some need qt5, and some fail if both are
enabled.

-- 
Rich

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 16:36, Rich Freeman пишет:
> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
>> 11.08.2015 16:11, James Le Cuirot пишет:
>>> On Tue, 11 Aug 2015 15:58:49 +0300
>>> Sergey Popov <pinkbyte@gentoo.org> wrote:
>>>
>>>> If both of flags are not set - we stick to default.
>>>> Should this be set in EVERY ebuild explicitly?
>>>>
>>>> Maybe provide some sugar like $(qt_use_default qtgui 5), where
>>>> qt_use_default is the name of function, qtgui is the package and 5 is
>>>> the slot for default choice, where either BOTH of flags(qt4, qt5) are
>>>> enabled or disabled
>>>
>>> That sounds a little bit like what I suggested earlier.
>>>
>>> https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df
>>>
>>
>> But without introducing brand new useless USE flag. Which makes huge
>> difference to me :-)
>>
> 
> If we want the typical user to not set either qt4 or qt5, are we
> saying that any package that could use either always enable one of
> them by default?  Then all users get a GUI by default, and then users
> have to explicitly disable it?  That seems to be the opposite of how
> we normally do things, but it does let you get away from having lots
> of users turning on qt.

I suggested this for packages, where GUI can not be disabled AND it
should be either qt4 or qt5. Then, if we do not add + to USE
description, users without anything in make.conf just run the blocker


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Rich Freeman]

On Tue, Aug 11, 2015 at 9:42 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
> 11.08.2015 16:36, Rich Freeman пишет:
>> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
>>> 11.08.2015 16:11, James Le Cuirot пишет:
>>>> On Tue, 11 Aug 2015 15:58:49 +0300
>>>> Sergey Popov <pinkbyte@gentoo.org> wrote:
>>>>
>>>>> If both of flags are not set - we stick to default.
>>>>> Should this be set in EVERY ebuild explicitly?
>>>>>
>>>>> Maybe provide some sugar like $(qt_use_default qtgui 5), where
>>>>> qt_use_default is the name of function, qtgui is the package and 5 is
>>>>> the slot for default choice, where either BOTH of flags(qt4, qt5) are
>>>>> enabled or disabled
>>>>
>>>> That sounds a little bit like what I suggested earlier.
>>>>
>>>> https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df
>>>>
>>>
>>> But without introducing brand new useless USE flag. Which makes huge
>>> difference to me :-)
>>>
>>
>> If we want the typical user to not set either qt4 or qt5, are we
>> saying that any package that could use either always enable one of
>> them by default?  Then all users get a GUI by default, and then users
>> have to explicitly disable it?  That seems to be the opposite of how
>> we normally do things, but it does let you get away from having lots
>> of users turning on qt.
>
> I suggested this for packages, where GUI can not be disabled AND it
> should be either qt4 or qt5. Then, if we do not add + to USE
> description, users without anything in make.conf just run the blocker
>

What if the GUI can be disabled?  Should we force users to set
USE="-qt4 -qt5" to disable the GUI?  Or should we force users to put
one of those in their make.conf or profile to enable it (causing
problems with packages that don't allow both)?

-- 
Rich

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 11/08/15 10:19 AM, Rich Freeman wrote:
> On Tue, Aug 11, 2015 at 9:42 AM, Sergey Popov <pinkbyte@gentoo.org>
> wrote:
>> 11.08.2015 16:36, Rich Freeman пишет:
>>> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov
>>> <pinkbyte@gentoo.org> wrote:
>>>> 11.08.2015 16:11, James Le Cuirot пишет:
>>>>> On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov
>>>>> <pinkbyte@gentoo.org> wrote:
>>>>> 
>>>>>> If both of flags are not set - we stick to default. 
>>>>>> Should this be set in EVERY ebuild explicitly?
>>>>>> 
>>>>>> Maybe provide some sugar like $(qt_use_default qtgui 5),
>>>>>> where qt_use_default is the name of function, qtgui is
>>>>>> the package and 5 is the slot for default choice, where
>>>>>> either BOTH of flags(qt4, qt5) are enabled or disabled
>>>>> 
>>>>> That sounds a little bit like what I suggested earlier.
>>>>> 
>>>>> https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d
629b1dc9b30df
>>>>>
>>>>
>>>>
>>>>> 
But without introducing brand new useless USE flag. Which makes huge
>>>> difference to me :-)
>>>> 
>>> 
>>> If we want the typical user to not set either qt4 or qt5, are
>>> we saying that any package that could use either always enable
>>> one of them by default?  Then all users get a GUI by default,
>>> and then users have to explicitly disable it?  That seems to be
>>> the opposite of how we normally do things, but it does let you
>>> get away from having lots of users turning on qt.
>> 
>> I suggested this for packages, where GUI can not be disabled AND
>> it should be either qt4 or qt5. Then, if we do not add + to USE 
>> description, users without anything in make.conf just run the
>> blocker
>> 
> 
> What if the GUI can be disabled?  Should we force users to set 
> USE="-qt4 -qt5" to disable the GUI?  Or should we force users to
> put one of those in their make.conf or profile to enable it
> (causing problems with packages that don't allow both)?
> 

I think the idea with USE="gui" is that the generic profiles then no
longer need any qt4/qt5/gtk3/whatever flags in them at all, and the
ebuilds themselves can set a single default-enable on the particular
flag that should be used by default, thus allowing REQUIRED_USE to be
satisfied by default when an end-user doesn't care.

However, I agree that USE=gui still has the problem where the
sub-flags have active state in VDB, meaning that any change to the
sub-flags will trigger rebuilds on -N even if USE="-gui".  And since
(if i understand this thread correctly) part of the reason for doing
all of this is to ensure VDB is as "accurate" as possible to what the
package actually uses/needs/depends on/etc, we end up not having
solved anything.


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

iF4EAREIAAYFAlXKEmUACgkQAJxUfCtlWe3fowEA6Sx5CtDme6K2h5Yu0yYrfUnb
2ZunvwQFlv4QAD+fQ1wA/3aX/kfviD+FttzxHgWBH3uGg1SX8DHNCFptfv9y2lJe
=6i3x
-----END PGP SIGNATURE-----

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 11/08/15 22:58, Sergey Popov wrote:
> 11.08.2015 15:30, Michael Palimaka пишет:
>> On 11/08/15 20:10, Sergey Popov wrote:
>>> Err, i have read the whole thread and still does not get a point, why i
>>> am wrong.
>>
>> You clearly have not. The reasoning behind Qt team's policy is described
>> on the page and has been reiterated on this list. You are undermining
>> what little confidence there is in the QA team by making decisions with
>> no consultation about problems you do not understand.
>>
>>> It's old battle like we have beforce with "gtk" meaning "any versions of
>>> GTK flag". This behaviour should be killed with fire.
>>>
>>> Let's me reiterate some of the cases:
>>>
>>> 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
>>> be chosen, but not both.
>>>
>>> Fix this with REQUIRED_USE, do not enable any of Qt flags by default
>>
>> Problem: this requires manual intervention if the user has both qt4 and
>> qt5 USE flags enabled.
>>
> 
> User choice of using USE flags is NOT a problem

I invite you to reproduce the problem yourself then make the judgement.
Using REQUIRED_USE like this makes the affected packages unusable.

>>>
>>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
>>> required, but not both
>>>
>>> Same thing here, different REQUIRED_USE operator. But - enable one of
>>> the flags by default to ease life of users.
>>
>> Problem: this requires manual intervention if the user has both qt4 and
>> qt5 USE flags enabled.
> 
> Same here
> 
>>>
>>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
>>> package even exists?)
>>>
>>> Do not use REQUIRED_USE here, not needed.
>>>
>>> Now, please tell me, where am i wrong?
>>>
>>
>> The problem is manual intervention is required if the user has both qt4
>> and qt5 USE flags enabled - and this is a common configuration. It is
>> not acceptable to make a user manually add numerous package.use entries
>> when all they want to do is install KDE.
> 
> And here
> 
>> I agree Qt's policy is not a perfect solution, but in the absence of
>> some feature allowing a preference to be set when there is a conflict
>> it's the best we've got.
>>
> 
> If you want to go this way, then please provide helper functions in
> eclasses to set dependencies properly for all common use cases. That
> will ease life both of developers and users.
> 
> Leaving constructing of dependencies to developers in all cases will
> cause only pain in your solution.
> 
> Look at the example with berkdb/gdbm, that i have posted recently.
> 
> If both of flags are not set - we stick to default.
> Should this be set in EVERY ebuild explicitly?
> 
> Maybe provide some sugar like $(qt_use_default qtgui 5), where
> qt_use_default is the name of function, qtgui is the package and 5 is
> the slot for default choice, where either BOTH of flags(qt4, qt5) are
> enabled or disabled

How does this solve the REQUIRED_USE problem? Or is your only objection
is that resulting dependency string is "too hard"?

Don't forget that as a project with no special authority, Qt's policy
remains a suggestion for the vast majority of maintainers. If someone
wishes to provide support for only one Qt version or abuse their users
with REQUIRED_USE they are still free to do so.

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 16:30, Michael Palimaka пишет:
> 
> Don't forget that as a project with no special authority, Qt's policy
> remains a suggestion for the vast majority of maintainers. If someone
> wishes to provide support for only one Qt version or abuse their users
> with REQUIRED_USE they are still free to do so.
> 

Not enforcing policies on main tree is a bad thing. If you make policy,
make other maintainers follow it. I am not against consistent policy
that ease life BOTH for developers and users.

You think that REQUIRED_USE is abusive to users: fine. Point accepted.
I think that provided DEPEND strings if they will be typed at every
single qt-related ebuild that needs them are abusive to developers.

So, maybe we should wrap them into eclass and stop riding our own
bicycles...

And then - use apropriate one-liner where it's needed, providing
reasonable default and NOT confusing users with overmanaging their
package.use

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 11/08/15 23:39, Sergey Popov wrote:
> 11.08.2015 16:30, Michael Palimaka пишет:
>>
>> Don't forget that as a project with no special authority, Qt's policy
>> remains a suggestion for the vast majority of maintainers. If someone
>> wishes to provide support for only one Qt version or abuse their users
>> with REQUIRED_USE they are still free to do so.
>>
> 
> Not enforcing policies on main tree is a bad thing. If you make policy,
> make other maintainers follow it. I am not against consistent policy
> that ease life BOTH for developers and users.

With what authority? Whether we like it or not, no project has any
formal authority to tell others how to handle "their" part of Gentoo.

> 
> You think that REQUIRED_USE is abusive to users: fine. Point accepted.
> I think that provided DEPEND strings if they will be typed at every
> single qt-related ebuild that needs them are abusive to developers.
> 
> So, maybe we should wrap them into eclass and stop riding our own
> bicycles...
> 
> And then - use apropriate one-liner where it's needed, providing
> reasonable default and NOT confusing users with overmanaging their
> package.use
> 

Please read Ben's original post again. Dependency strings are not the topic.

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 16:49, Michael Palimaka пишет:
>> You think that REQUIRED_USE is abusive to users: fine. Point accepted.
>> I think that provided DEPEND strings if they will be typed at every
>> single qt-related ebuild that needs them are abusive to developers.
>>
>> So, maybe we should wrap them into eclass and stop riding our own
>> bicycles...
>>
>> And then - use apropriate one-liner where it's needed, providing
>> reasonable default and NOT confusing users with overmanaging their
>> package.use
>>
> 
> Please read Ben's original post again. Dependency strings are not the topic.
> 
> 

If introducing new USE-flags or ignoring using REQUIRED_USE leads to
blowing the DEPEND variable, adding pain for the developers - it is the
topic, definitely

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 13/08/15 18:17, Sergey Popov wrote:
> 11.08.2015 16:49, Michael Palimaka пишет:
>>> You think that REQUIRED_USE is abusive to users: fine. Point accepted.
>>> I think that provided DEPEND strings if they will be typed at every
>>> single qt-related ebuild that needs them are abusive to developers.
>>>
>>> So, maybe we should wrap them into eclass and stop riding our own
>>> bicycles...
>>>
>>> And then - use apropriate one-liner where it's needed, providing
>>> reasonable default and NOT confusing users with overmanaging their
>>> package.use
>>>
>>
>> Please read Ben's original post again. Dependency strings are not the topic.
>>
>>
> 
> If introducing new USE-flags or ignoring using REQUIRED_USE leads to
> blowing the DEPEND variable, adding pain for the developers - it is the
> topic, definitely
> 

Seriously, read the original post again. It's about handling of packages
that offer a choice between qt4 and qt5 and how to present that to the user.

It's not about the size of dependency strings, banning REQUIRED_USE,
project policy enforcement or anything else. If you wish to discuss
those topics please create a new thread and stop derailing this one.

Re: [gentoo-dev] Re: useflag policies

[Rich Freeman]

On Tue, Aug 11, 2015 at 9:39 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
> 11.08.2015 16:30, Michael Palimaka пишет:
>>
>> Don't forget that as a project with no special authority, Qt's policy
>> remains a suggestion for the vast majority of maintainers. If someone
>> wishes to provide support for only one Qt version or abuse their users
>> with REQUIRED_USE they are still free to do so.
>>
>
> Not enforcing policies on main tree is a bad thing. If you make policy,
> make other maintainers follow it. I am not against consistent policy
> that ease life BOTH for developers and users.

++

I think the qt team taking the lead on this makes sense, but this is
the sort of thing that just makes sense as a treewide policy.  If
people don't like their suggested policy they can take it to
QA/council/whatever, but it makes more sense to have projects setting
standards than having everybody doing their own thing.

I realize this is frustrating and contentious, but I think we're
better off hashing this out, and implementing something reasonable,
than having a bazillion different conventions that users have to deal
with.  Usually I prefer maintainer autonomy, but this is just one of
those times it doesn't make sense.

-- 
Rich

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 12/08/15 00:29, Rich Freeman wrote:
> On Tue, Aug 11, 2015 at 9:39 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
>> 11.08.2015 16:30, Michael Palimaka пишет:
>>>
>>> Don't forget that as a project with no special authority, Qt's policy
>>> remains a suggestion for the vast majority of maintainers. If someone
>>> wishes to provide support for only one Qt version or abuse their users
>>> with REQUIRED_USE they are still free to do so.
>>>
>>
>> Not enforcing policies on main tree is a bad thing. If you make policy,
>> make other maintainers follow it. I am not against consistent policy
>> that ease life BOTH for developers and users.
> 
> ++
> 
> I think the qt team taking the lead on this makes sense, but this is
> the sort of thing that just makes sense as a treewide policy.  If
> people don't like their suggested policy they can take it to
> QA/council/whatever, but it makes more sense to have projects setting
> standards than having everybody doing their own thing.
> 
> I realize this is frustrating and contentious, but I think we're
> better off hashing this out, and implementing something reasonable,
> than having a bazillion different conventions that users have to deal
> with.  Usually I prefer maintainer autonomy, but this is just one of
> those times it doesn't make sense.
> 

Isn't this moving towards a situation that we used GLEP 39 to remove?

Re: [gentoo-dev] Re: useflag policies

[Rich Freeman]

On Tue, Aug 11, 2015 at 10:42 AM, Michael Palimaka
<kensington@gentoo.org> wrote:
> On 12/08/15 00:29, Rich Freeman wrote:
>>
>> I realize this is frustrating and contentious, but I think we're
>> better off hashing this out, and implementing something reasonable,
>> than having a bazillion different conventions that users have to deal
>> with.  Usually I prefer maintainer autonomy, but this is just one of
>> those times it doesn't make sense.
>>
>
> Isn't this moving towards a situation that we used GLEP 39 to remove?
>

Fair enough.  I don't really have a problem with the qt team proposing
a policy and having QA or the Council bless it.  Or having a more
general policy and the QA policy is just an instance of it.

-- 
Rich

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Tue, 11 Aug 2015 23:30:31 +1000
Michael Palimaka <kensington@gentoo.org> wrote:
> I invite you to reproduce the problem yourself then make the
> judgement. Using REQUIRED_USE like this makes the affected packages
> unusable.

Can't we all (except for the usual suspect) just agree that REQUIRED_USE
was a mistake, and go back to pkg_pretend? The only justification for
REQUIRED_USE was that it could allegedly be used in an automated
fashion, and this hasn't happened.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 05:21:20 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 11 Aug 2015 23:30:31 +1000
> Michael Palimaka <kensington@gentoo.org> wrote:
> > I invite you to reproduce the problem yourself then make the
> > judgement. Using REQUIRED_USE like this makes the affected packages
> > unusable.
> 
> Can't we all (except for the usual suspect) just agree that
> REQUIRED_USE was a mistake, and go back to pkg_pretend? The only
> justification for REQUIRED_USE was that it could allegedly be used in
> an automated fashion, and this hasn't happened.

+1

or restrict it so that it is not yet another sat instance


i.e. something that really tells the PM how to automate the choice:
- 'qt5 -> !qt4' is rather straightforward to solve and tells the PM how
  (note that it is not equivalent to 'qt4 -> !qt5')
- '^^ ( qt5 qt4 )' requires the PM to make a choice in order to
  automate it

Re: [gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote:

> i.e. something that really tells the PM how to automate the choice:
> - 'qt5 -> !qt4' is rather straightforward to solve and tells the PM how
>   (note that it is not equivalent to 'qt4 -> !qt5')
> - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to
>   automate it

I was thinking about some syntax like this:

   REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"

The package manager would first evaluate each group in REQUIRED_USE
with the original set of USE flags. If that doesn't evaluate to true,
retry with flags changed as indicated by the + and - signs.

Ulrich

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

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 11:08 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote:
> 
>> i.e. something that really tells the PM how to automate the
>> choice: - 'qt5 -> !qt4' is rather straightforward to solve and
>> tells the PM how (note that it is not equivalent to 'qt4 ->
>> !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in
>> order to automate it
> 
> I was thinking about some syntax like this:
> 
> REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"
> 
> The package manager would first evaluate each group in
> REQUIRED_USE with the original set of USE flags. If that doesn't
> evaluate to true, retry with flags changed as indicated by the +
> and - signs.
> 
> Ulrich
> 

Having the ability for REQUIRED_USE to provide a default resolution
path should definitely help with things; I assume this is meant to
do its work via --autounmask-write or similar, ie to help users
adjust their config files?  Or was the thought to allow PMs to
override USE immediately?

Questions:

1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE?

2 - is there a particular reasoning for the - in front of qt4 here?
 I only ask because it would seem that a single default-enable
should suffice in lists like this to indicate a resolution path, no?
 That is, '^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like it
would be the same as '^^ ( +flag1 flag2 flag3 flag4 )'

3 - will having REQUIRED_USE be able to force flags on (and others
off) likely result in abuse of profiles and other use defaults?  I
forsee this being a way, for instance, for a dev to get around users
setting USE="-*" in make.conf to ensure a default use flag setting
is honoured.

4 - Will a change to which flag the '+' is on likely to require a
revbump for VDB updates?  For something like '^^ ( +qt4 qt5 )' I
could see maintainers wanting to switch which flag is default across
a bunch of packages at once when, say, the qt team wants qt5 to
become the de-facto default.

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

iF4EAREIAAYFAlXLZp8ACgkQAJxUfCtlWe0NcgEAzt6FjitYEyk6h2HufX4WiKko
tldpUk71Wnj+y5ejB38A/R23oq0E4PakpXg5ML8pqG8gPnyXJmIN8Fuh6Gj1Y+6Y
=UaQK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 11:30:39 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/08/15 11:08 AM, Ulrich Mueller wrote:
> >>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote:
> > 
> >> i.e. something that really tells the PM how to automate the
> >> choice: - 'qt5 -> !qt4' is rather straightforward to solve and
> >> tells the PM how (note that it is not equivalent to 'qt4 ->
> >> !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in
> >> order to automate it
> > 
> > I was thinking about some syntax like this:
> > 
> > REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"
> > 
> > The package manager would first evaluate each group in
> > REQUIRED_USE with the original set of USE flags. If that doesn't
> > evaluate to true, retry with flags changed as indicated by the +
> > and - signs.
> > 
> > Ulrich
> > 
> 
> Having the ability for REQUIRED_USE to provide a default resolution
> path should definitely help with things; I assume this is meant to
> do its work via --autounmask-write or similar, ie to help users
> adjust their config files?  Or was the thought to allow PMs to
> override USE immediately?


I think it is better seen as a list of implications, esp. for this kind
of questions :)
With that in mind, there is no autounmask-write: effective USE for a
given package is input USE with these implications applied.

> Questions:
> 
> 1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE?

This questions remains. I see use-defaults in IUSE as part of "input
USE" above.


[...]
> 3 - will having REQUIRED_USE be able to force flags on (and others
> off) likely result in abuse of profiles and other use defaults?  I
> forsee this being a way, for instance, for a dev to get around users
> setting USE="-*" in make.conf to ensure a default use flag setting
> is honoured.

How?

> 4 - Will a change to which flag the '+' is on likely to require a
> revbump for VDB updates?  For something like '^^ ( +qt4 qt5 )' I
> could see maintainers wanting to switch which flag is default across
> a bunch of packages at once when, say, the qt team wants qt5 to
> become the de-facto default.

It'll "require" a rebuild for those whose default changes anyway. I'd
say no revbump since we don't revbump all affected packages when we add
default enabled flags to make.defaults.


Alexis.

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 11:55 AM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 12/08/15 11:08 AM, Ulrich Mueller wrote:
>>>>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote:
>>> 
>>>> i.e. something that really tells the PM how to automate
>>>> the choice: - 'qt5 -> !qt4' is rather straightforward to
>>>> solve and tells the PM how (note that it is not equivalent
>>>> to 'qt4 -> !qt5') - '^^ ( qt5 qt4 )' requires the PM to
>>>> make a choice in order to automate it
>>> 
>>> I was thinking about some syntax like this:
>>> 
>>> REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"
>>> 
>>> The package manager would first evaluate each group in 
>>> REQUIRED_USE with the original set of USE flags. If that
>>> doesn't evaluate to true, retry with flags changed as
>>> indicated by the + and - signs.
>>> 
>>> Ulrich
>>> 
>> 
>> Having the ability for REQUIRED_USE to provide a default
>> resolution path should definitely help with things; I assume
>> this is meant to do its work via --autounmask-write or similar,
>> ie to help users adjust their config files?  Or was the thought
>> to allow PMs to override USE immediately?
> 
> 
> I think it is better seen as a list of implications, esp. for
> this kind of questions :) With that in mind, there is no
> autounmask-write: effective USE for a given package is input USE
> with these implications applied.

..if I'm understanding what you're saying here, you see this as
something the PM will use to adjust the input use list so that the
emerge itself will go ahead with the newly adjusted flags; am I
understanding that correctly?

In other words, there won't be any user control/alert/override for
what the default actions will be, if the user's profile isn't set up
in a way that satisfies REQUIRED_USE, correct?  so if I have
'app-cat/pkg qt4' in my package.use, but USE="qt5" in my profile,
then because both flags end up being enabled the REQUIRED_USE="^^ (
+qt5 qt4 )" in app-cat/pkg will just force-off my package.use entry
and everything will proceed as if it wasn't there?


> 
>> Questions:
>> 
>> 1 - how does +foo in REQUIRED_USE relate to use-defaults set in
>> IUSE?
> 
> This questions remains. I see use-defaults in IUSE as part of
> "input USE" above.

Yes, just as it is now, the use-defaults in IUSE are part of the
"input use".  What I'm wondering is, would the +foo in
REQUIRED_USE="|| ( +foo bar )" be something that should be used in
combination with IUSE="+foo" (perhaps even require it) or would its
functionality and specification be entirely independent of it?
Right now for ||(), setting IUSE="+foo" gets around that issue in
almost all cases, the only case it doesn't is when the user has
explicitly set USE="-foo" (or USE="-*").


> 
> 
> [...]
>> 3 - will having REQUIRED_USE be able to force flags on (and
>> others off) likely result in abuse of profiles and other use
>> defaults?  I forsee this being a way, for instance, for a dev
>> to get around users setting USE="-*" in make.conf to ensure a
>> default use flag setting is honoured.
> 
> How?

This assumes that the PM will just set the flags that resolve the
REQUIRED_USE directly (ie modify the "input use" based on the
defaults provided) and go ahead, which seems to be what you're
implying will be the implementation, earlier on. See my response re
#1 above as well, since if I understand this correctly the
REQUIRED_USE="|| ( +foo bar )" will set +foo even if USE="-*" in the
profile right?


> 
>> 4 - Will a change to which flag the '+' is on likely to require
>> a revbump for VDB updates?  For something like '^^ ( +qt4 qt5
>> )' I could see maintainers wanting to switch which flag is
>> default across a bunch of packages at once when, say, the qt
>> team wants qt5 to become the de-facto default.
> 
> It'll "require" a rebuild for those whose default changes anyway.
> I'd say no revbump since we don't revbump all affected packages
> when we add default enabled flags to make.defaults.

Thinking about it I think I answered my own question, in that there
shouldn't be any need for this to affect VDB since the end-result is
expressed in the state recorded in 'USE'.  And no VDB change means
no need for a revbump.  Whether or not the change results in a
rebuild on -N will depend on whether or not the state of the user's
profile will result in a REQUIRED_USE conflict that needs to be
default-resolved or not, and that's true from emerge to emerge no
matter what.


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

iF4EAREIAAYFAlXLc+MACgkQAJxUfCtlWe3GKgEAvfYZ3SD2NcKCeZjf4qlfzy2G
Fjzfub0X2BfuiAVJnbgA/RIaxTQRGt7PL693qNS3HxOX/q2T7l6W3Hv105NeBTlT
=S9wv
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:

> On 12/08/15 11:55 AM, Alexis Ballier wrote:
>> I think it is better seen as a list of implications, esp. for
>> this kind of questions :) With that in mind, there is no
>> autounmask-write: effective USE for a given package is input USE
>> with these implications applied.

This very well summarises it.

> ..if I'm understanding what you're saying here, you see this as
> something the PM will use to adjust the input use list so that the
> emerge itself will go ahead with the newly adjusted flags; am I
> understanding that correctly?

> In other words, there won't be any user control/alert/override for
> what the default actions will be, if the user's profile isn't set up
> in a way that satisfies REQUIRED_USE, correct?  so if I have
> 'app-cat/pkg qt4' in my package.use, but USE="qt5" in my profile,
> then because both flags end up being enabled the REQUIRED_USE="^^ (
> +qt5 qt4 )" in app-cat/pkg will just force-off my package.use entry
> and everything will proceed as if it wasn't there?

Indeed, maybe there would be too much magic at work there. However,
note that also currently you won't be able to emerge the package with
a package.use that results in conflicting flags.

Ulrich

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

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 12:53 PM, Ulrich Mueller wrote:
>>>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
> 
>> On 12/08/15 11:55 AM, Alexis Ballier wrote:
>>> I think it is better seen as a list of implications, esp.
>>> for this kind of questions :) With that in mind, there is no 
>>> autounmask-write: effective USE for a given package is input
>>> USE with these implications applied.
> 
> This very well summarises it.
> 
>> ..if I'm understanding what you're saying here, you see this
>> as something the PM will use to adjust the input use list so
>> that the emerge itself will go ahead with the newly adjusted
>> flags; am I understanding that correctly?
> 
>> In other words, there won't be any user control/alert/override
>> for what the default actions will be, if the user's profile
>> isn't set up in a way that satisfies REQUIRED_USE, correct?  so
>> if I have 'app-cat/pkg qt4' in my package.use, but USE="qt5" in
>> my profile, then because both flags end up being enabled the
>> REQUIRED_USE="^^ ( +qt5 qt4 )" in app-cat/pkg will just
>> force-off my package.use entry and everything will proceed as
>> if it wasn't there?
> 
> Indeed, maybe there would be too much magic at work there.
> However, note that also currently you won't be able to emerge the
> package with a package.use that results in conflicting flags.
> 
> Ulrich
> 

How would that be determined, then?  These REQUIRED_USE flag forces
would somehow occur in between the USE= assignment from the
profile/make.conf and the entries from package.use ?

This is why I was wondering if it'd make more sense for these
REQUIRE_USE defaults to just help portage resolve the deptree, and
then --autounmask-write to fix package.use to match before
proceeding.  Not as nice to end-users I know, but at least portage
would resolve currently-unresolvable solutions to a known default;
afaik portage can't even suggest a default solution the way things
are now, can it?



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

iF4EAREIAAYFAlXLfAIACgkQAJxUfCtlWe1LhgEAtWKXnWtYLGxt/o6e+cKSXn3u
VWidCNO/QKlT9Ji5uQQA/R9biZJqccv4I64JFW9tKWKAuWA3S67VaE9Rj/QZ3GNy
=Mbw/
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 12:27:15 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/08/15 11:55 AM, Alexis Ballier wrote:
> > On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius
> > <axs@gentoo.org> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >> 
> >> On 12/08/15 11:08 AM, Ulrich Mueller wrote:
> >>>>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote:
> >>> 
> >>>> i.e. something that really tells the PM how to automate
> >>>> the choice: - 'qt5 -> !qt4' is rather straightforward to
> >>>> solve and tells the PM how (note that it is not equivalent
> >>>> to 'qt4 -> !qt5') - '^^ ( qt5 qt4 )' requires the PM to
> >>>> make a choice in order to automate it
> >>> 
> >>> I was thinking about some syntax like this:
> >>> 
> >>> REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"
> >>> 
> >>> The package manager would first evaluate each group in 
> >>> REQUIRED_USE with the original set of USE flags. If that
> >>> doesn't evaluate to true, retry with flags changed as
> >>> indicated by the + and - signs.
> >>> 
> >>> Ulrich
> >>> 
> >> 
> >> Having the ability for REQUIRED_USE to provide a default
> >> resolution path should definitely help with things; I assume
> >> this is meant to do its work via --autounmask-write or similar,
> >> ie to help users adjust their config files?  Or was the thought
> >> to allow PMs to override USE immediately?
> > 
> > 
> > I think it is better seen as a list of implications, esp. for
> > this kind of questions :) With that in mind, there is no
> > autounmask-write: effective USE for a given package is input USE
> > with these implications applied.
> 
> ..if I'm understanding what you're saying here, you see this as
> something the PM will use to adjust the input use list so that the
> emerge itself will go ahead with the newly adjusted flags; am I
> understanding that correctly?
> 
> In other words, there won't be any user control/alert/override for
> what the default actions will be, if the user's profile isn't set up
> in a way that satisfies REQUIRED_USE, correct?  so if I have
> 'app-cat/pkg qt4' in my package.use, but USE="qt5" in my profile,
> then because both flags end up being enabled the REQUIRED_USE="^^ (
> +qt5 qt4 )" in app-cat/pkg will just force-off my package.use entry
> and everything will proceed as if it wasn't there?
> 
> 
> > 
> >> Questions:
> >> 
> >> 1 - how does +foo in REQUIRED_USE relate to use-defaults set in
> >> IUSE?
> > 
> > This questions remains. I see use-defaults in IUSE as part of
> > "input USE" above.
> 
> Yes, just as it is now, the use-defaults in IUSE are part of the
> "input use".  What I'm wondering is, would the +foo in
> REQUIRED_USE="|| ( +foo bar )" be something that should be used in
> combination with IUSE="+foo" (perhaps even require it) or would its
> functionality and specification be entirely independent of it?
> Right now for ||(), setting IUSE="+foo" gets around that issue in
> almost all cases, the only case it doesn't is when the user has
> explicitly set USE="-foo" (or USE="-*").
> 
> 
> > 
> > 
> > [...]
> >> 3 - will having REQUIRED_USE be able to force flags on (and
> >> others off) likely result in abuse of profiles and other use
> >> defaults?  I forsee this being a way, for instance, for a dev
> >> to get around users setting USE="-*" in make.conf to ensure a
> >> default use flag setting is honoured.
> > 
> > How?
> 
> This assumes that the PM will just set the flags that resolve the
> REQUIRED_USE directly (ie modify the "input use" based on the
> defaults provided) and go ahead, which seems to be what you're
> implying will be the implementation, earlier on. See my response re
> #1 above as well, since if I understand this correctly the
> REQUIRED_USE="|| ( +foo bar )" will set +foo even if USE="-*" in the
> profile right?


Answering all the above questions I think: input use and "effective"
use are unrelated. The point here is to give PM a way to solve
REQUIRED_USE which we currently lack. How PM does it: by
autounmask-write, a warning, an error (as currently), or silently is up
to each user's preference. I agree though that forcibly solving the
conflicts silently might not be a terrible idea and it'd be much better
to have an option to control that behavior.


Alexis.

Re: [gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote:

> it is more in the line of what we currently do, but that doesn't
> resolve the 'sat' problem: it doesnt make clear we don't want to
> satisfy it but rather walk through a list of causes and consequences

> now that i'm thinking more about it, killing || and ^^ would
> probably solve the automation problem:
> qt? ( !qt4? ( qt5 ) qt4? ( !qt5 ) ) vs 'qt? ( ^^ ( qt4 qt5 ) )'

> a bit longer but PM now knows what to do

> [...]

> No need for a new syntax :)

Indeed.

What is the general opinion, would it be worth the price of somewhat
longer expressions?

Ulrich

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

Re: [gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:

> On 12/08/15 11:08 AM, Ulrich Mueller wrote:
>> I was thinking about some syntax like this:
>> 
>> REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"
>> 
>> The package manager would first evaluate each group in
>> REQUIRED_USE with the original set of USE flags. If that doesn't
>> evaluate to true, retry with flags changed as indicated by the +
>> and - signs.

> Having the ability for REQUIRED_USE to provide a default resolution
> path should definitely help with things; I assume this is meant to
> do its work via --autounmask-write or similar, ie to help users
> adjust their config files?  Or was the thought to allow PMs to
> override USE immediately?

In fact, I was thinking about overriding it immediately. It is the
same as the ebuild explicitly picking a working default from
conflicting flags, where there is also no user interaction required.
(The PM should emit a warning, though.)

> Questions:

> 1 - how does +foo in REQUIRED_USE relate to use-defaults set in
> IUSE?

Apart from the similar syntax, they are not related.

> 2 - is there a particular reasoning for the - in front of qt4 here?
>  I only ask because it would seem that a single default-enable
> should suffice in lists like this to indicate a resolution path, no?
>  That is, '^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like it
> would be the same as '^^ ( +flag1 flag2 flag3 flag4 )'

If the user has both "qt4 qt5", then enabling qt5 alone won't help to
resolve "^^ ( qt5 qt4 )".

> 3 - will having REQUIRED_USE be able to force flags on (and others
> off) likely result in abuse of profiles and other use defaults?

It wouldn't look for the origin of a USE flag setting in its input
data. So, yes.

> I forsee this being a way, for instance, for a dev to get around
> users setting USE="-*" in make.conf to ensure a default use flag
> setting is honoured.

> 4 - Will a change to which flag the '+' is on likely to require a
> revbump for VDB updates?

I don't think so. For Portage users, it would be handled by --newuse,
I guess.

> For something like '^^ ( +qt4 qt5 )' I could see maintainers wanting
> to switch which flag is default across a bunch of packages at once
> when, say, the qt team wants qt5 to become the de-facto default.

Ulrich

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

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 12:42 PM, Ulrich Mueller wrote:
> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
>> 2 - is there a particular reasoning for the - in front of qt4
>> here? I only ask because it would seem that a single
>> default-enable should suffice in lists like this to indicate a
>> resolution path, no? That is, '^^ ( +flag1 -flag2 -flag3 -flag4
>> )' to me seems like it would be the same as '^^ ( +flag1 flag2
>> flag3 flag4 )'
> 
> If the user has both "qt4 qt5", then enabling qt5 alone won't
> help to resolve "^^ ( qt5 qt4 )".
> 

Right, but the PM knows based on a particular REQUIRED_USE operator
what it would need to do when a particular flag is set to default.
Given '^^' is must-be-one-of, the +flag would be enabled and all the
other flags would be disabled, right?

Here's how I'd see it mapping out:

|| ( +flag1 flag2 ... ) , PM only forces-on flag1
^^ ( +flag1 flag2 ... ) , PM forces-on flag1, forces-off all others
?? ( +flag2 flag2 ... ) , PM forces off all but flag1

I'm not sure if the following make sense though... thoughts?

{,!}flag1? ( +flag2 ) , PM forces-on flag2
{,!}flag1? ( +!flag2 ) , PM forces !flag2, meaning forces-off flag2


I'm just wondering if it's really necessary in terms of syntax to
specify the flag-negation that the PM would need to do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXLevUACgkQAJxUfCtlWe2egAD+K8DCAD4UfqR3A6GKNBcSzIL9
9NaJrt8TX/LRl3uSP8MBAJjwh5ybmY42dEe3lTBlHhlAv7entRSdzKM6tmwB26WW
=scA5
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 12:57:25 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
> > On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
> >> 2 - is there a particular reasoning for the - in front of qt4
> >> here? I only ask because it would seem that a single
> >> default-enable should suffice in lists like this to indicate a
> >> resolution path, no? That is, '^^ ( +flag1 -flag2 -flag3 -flag4
> >> )' to me seems like it would be the same as '^^ ( +flag1 flag2
> >> flag3 flag4 )'
> > 
> > If the user has both "qt4 qt5", then enabling qt5 alone won't
> > help to resolve "^^ ( qt5 qt4 )".
> > 
> 
> Right, but the PM knows based on a particular REQUIRED_USE operator
> what it would need to do when a particular flag is set to default.
> Given '^^' is must-be-one-of, the +flag would be enabled and all the
> other flags would be disabled, right?
> 
> Here's how I'd see it mapping out:
> 
> || ( +flag1 flag2 ... ) , PM only forces-on flag1
> ^^ ( +flag1 flag2 ... ) , PM forces-on flag1, forces-off all others
> ?? ( +flag2 flag2 ... ) , PM forces off all but flag1
> 
> I'm not sure if the following make sense though... thoughts?
> 
> {,!}flag1? ( +flag2 ) , PM forces-on flag2
> {,!}flag1? ( +!flag2 ) , PM forces !flag2, meaning forces-off flag2
> 
> 
> I'm just wondering if it's really necessary in terms of syntax to
> specify the flag-negation that the PM would need to do.


See my other email: neither + nor - are necessary :)

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 01:00 PM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
>>>> 2 - is there a particular reasoning for the - in front of
>>>> qt4 here? I only ask because it would seem that a single 
>>>> default-enable should suffice in lists like this to
>>>> indicate a resolution path, no? That is, '^^ ( +flag1
>>>> -flag2 -flag3 -flag4 )' to me seems like it would be the
>>>> same as '^^ ( +flag1 flag2 flag3 flag4 )'
>>> 
>>> If the user has both "qt4 qt5", then enabling qt5 alone
>>> won't help to resolve "^^ ( qt5 qt4 )".
>>> 
>> 
>> Right, but the PM knows based on a particular REQUIRED_USE
>> operator what it would need to do when a particular flag is set
>> to default. Given '^^' is must-be-one-of, the +flag would be
>> enabled and all the other flags would be disabled, right?
>> 
>> Here's how I'd see it mapping out:
>> 
>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ ( +flag1
>> flag2 ... ) , PM forces-on flag1, forces-off all others ?? (
>> +flag2 flag2 ... ) , PM forces off all but flag1
>> 
>> I'm not sure if the following make sense though... thoughts?
>> 
>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? ( +!flag2
>> ) , PM forces !flag2, meaning forces-off flag2
>> 
>> 
>> I'm just wondering if it's really necessary in terms of syntax
>> to specify the flag-negation that the PM would need to do.
> 
> 
> See my other email: neither + nor - are necessary :)
> 
> 


I'd disagree on that -- technically they aren't necessary, but the
whole reason why these new operators were added in the first place
was so that it's a lot easier for developers to fill in REQUIRED_USE
and get the logic right.  Mapping out a ^^ ( flag1 flag2 flag3 flag4
) into all of its permissible flag-a? ( flagb !flagc !flagd )
variants is a royal pain.  Plus there's
readability/understandability to consider here.



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

iF4EAREIAAYFAlXLfMYACgkQAJxUfCtlWe3JpQD9Gt87cclSsz3FTw5KbnlsSjVX
zf4FXOa4IMI4AcRCy+EA/37u0n/USxmMUDQxbVZT7Kp4O9EkdYR/DdNHQNUlBYMe
=Cpmr
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
> On 12/08/15 01:00 PM, Alexis Ballier wrote:
>> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius 
>> <axs@gentoo.org> wrote:
> 
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>> 
>>> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
>>>>> 2 - is there a particular reasoning for the - in front
>>>>> of qt4 here? I only ask because it would seem that a
>>>>> single default-enable should suffice in lists like this
>>>>> to indicate a resolution path, no? That is, '^^ ( +flag1 
>>>>> -flag2 -flag3 -flag4 )' to me seems like it would be the 
>>>>> same as '^^ ( +flag1 flag2 flag3 flag4 )'
>>>> 
>>>> If the user has both "qt4 qt5", then enabling qt5 alone 
>>>> won't help to resolve "^^ ( qt5 qt4 )".
>>>> 
>>> 
>>> Right, but the PM knows based on a particular REQUIRED_USE 
>>> operator what it would need to do when a particular flag is
>>> set to default. Given '^^' is must-be-one-of, the +flag would
>>> be enabled and all the other flags would be disabled, right?
>>> 
>>> Here's how I'd see it mapping out:
>>> 
>>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ (
>>> +flag1 flag2 ... ) , PM forces-on flag1, forces-off all
>>> others ?? ( +flag2 flag2 ... ) , PM forces off all but flag1
>>> 
>>> I'm not sure if the following make sense though... thoughts?
>>> 
>>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? (
>>> +!flag2 ) , PM forces !flag2, meaning forces-off flag2
>>> 
>>> 
>>> I'm just wondering if it's really necessary in terms of
>>> syntax to specify the flag-negation that the PM would need to
>>> do.
> 
> 
>> See my other email: neither + nor - are necessary :)
> 
> 
> 
> 
> I'd disagree on that -- technically they aren't necessary, but
> the whole reason why these new operators were added in the first
> place was so that it's a lot easier for developers to fill in
> REQUIRED_USE and get the logic right.  Mapping out a ^^ ( flag1
> flag2 flag3 flag4 ) into all of its permissible flag-a? ( flagb
> !flagc !flagd ) variants is a royal pain.  Plus there's 
> readability/understandability to consider here.
> 

err, flaga? ( !flagb !flagc !flagd )  i mean..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXLfSMACgkQAJxUfCtlWe3jQQD7B9BCbF/3qfE9sQCygNpxKhlo
svefcKCbomBA6fTg6bsA/0QLz/Qw8nL4d7P9I4fruwgyU1vZb/VIBmXynwbAij2L
=NW7S
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 13:06:43 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
> > On 12/08/15 01:00 PM, Alexis Ballier wrote:
> >> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius 
> >> <axs@gentoo.org> wrote:
> > 
> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>> 
> >>> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
> >>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
> >>>>> 2 - is there a particular reasoning for the - in front
> >>>>> of qt4 here? I only ask because it would seem that a
> >>>>> single default-enable should suffice in lists like this
> >>>>> to indicate a resolution path, no? That is, '^^ ( +flag1 
> >>>>> -flag2 -flag3 -flag4 )' to me seems like it would be the 
> >>>>> same as '^^ ( +flag1 flag2 flag3 flag4 )'
> >>>> 
> >>>> If the user has both "qt4 qt5", then enabling qt5 alone 
> >>>> won't help to resolve "^^ ( qt5 qt4 )".
> >>>> 
> >>> 
> >>> Right, but the PM knows based on a particular REQUIRED_USE 
> >>> operator what it would need to do when a particular flag is
> >>> set to default. Given '^^' is must-be-one-of, the +flag would
> >>> be enabled and all the other flags would be disabled, right?
> >>> 
> >>> Here's how I'd see it mapping out:
> >>> 
> >>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ (
> >>> +flag1 flag2 ... ) , PM forces-on flag1, forces-off all
> >>> others ?? ( +flag2 flag2 ... ) , PM forces off all but flag1
> >>> 
> >>> I'm not sure if the following make sense though... thoughts?
> >>> 
> >>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? (
> >>> +!flag2 ) , PM forces !flag2, meaning forces-off flag2
> >>> 
> >>> 
> >>> I'm just wondering if it's really necessary in terms of
> >>> syntax to specify the flag-negation that the PM would need to
> >>> do.
> > 
> > 
> >> See my other email: neither + nor - are necessary :)
> > 
> > 
> > 
> > 
> > I'd disagree on that -- technically they aren't necessary, but
> > the whole reason why these new operators were added in the first
> > place was so that it's a lot easier for developers to fill in
> > REQUIRED_USE and get the logic right.  Mapping out a ^^ ( flag1
> > flag2 flag3 flag4 ) into all of its permissible flag-a? ( flagb
> > !flagc !flagd ) variants is a royal pain.  Plus there's 
> > readability/understandability to consider here.
> > 
> 
> err, flaga? ( !flagb !flagc !flagd )  i mean..

It is indeed longer (n flags to roughly n² flags expanded i'd say), but
i disagree on the readability: i find it much more readable as "if
flaga is enabled then flagb, flagc and flagd must be disabled" etc.
which express clearly the preference than "exactly one of flaga flagb
flagc flagd except if there is a problem then flaga but not the others".

Also, there's something we've overseen with the +/- syntax: What about
"^^ ( +flaga -flagb -flagc -flagd )" with USE="-flaga flagb flagc" ?
The only way to solve it would be USE="flaga -flagb -flagc" while the
"implication syntax" could give you USE="-flaga flagb -flagc" (or any
other preference of the ebuild writer).

Finally, about getting the logic right, since it's a subset of the
current syntax I don't think that should be a problem :)

Alexis.

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 01:22 PM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
>>> On 12/08/15 01:00 PM, Alexis Ballier wrote:
>>>> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius 
>>>> <axs@gentoo.org> wrote:
>>> 
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>> 
>>>>> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
>>>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
>>>>>>> 2 - is there a particular reasoning for the - in
>>>>>>> front of qt4 here? I only ask because it would seem
>>>>>>> that a single default-enable should suffice in lists
>>>>>>> like this to indicate a resolution path, no? That is,
>>>>>>> '^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like
>>>>>>> it would be the same as '^^ ( +flag1 flag2 flag3
>>>>>>> flag4 )'
>>>>>> 
>>>>>> If the user has both "qt4 qt5", then enabling qt5 alone
>>>>>>  won't help to resolve "^^ ( qt5 qt4 )".
>>>>>> 
>>>>> 
>>>>> Right, but the PM knows based on a particular
>>>>> REQUIRED_USE operator what it would need to do when a
>>>>> particular flag is set to default. Given '^^' is
>>>>> must-be-one-of, the +flag would be enabled and all the
>>>>> other flags would be disabled, right?
>>>>> 
>>>>> Here's how I'd see it mapping out:
>>>>> 
>>>>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ ( 
>>>>> +flag1 flag2 ... ) , PM forces-on flag1, forces-off all 
>>>>> others ?? ( +flag2 flag2 ... ) , PM forces off all but
>>>>> flag1
>>>>> 
>>>>> I'm not sure if the following make sense though...
>>>>> thoughts?
>>>>> 
>>>>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? ( 
>>>>> +!flag2 ) , PM forces !flag2, meaning forces-off flag2
>>>>> 
>>>>> 
>>>>> I'm just wondering if it's really necessary in terms of 
>>>>> syntax to specify the flag-negation that the PM would
>>>>> need to do.
>>> 
>>> 
>>>> See my other email: neither + nor - are necessary :)
>>> 
>>> 
>>> 
>>> 
>>> I'd disagree on that -- technically they aren't necessary,
>>> but the whole reason why these new operators were added in
>>> the first place was so that it's a lot easier for developers
>>> to fill in REQUIRED_USE and get the logic right.  Mapping out
>>> a ^^ ( flag1 flag2 flag3 flag4 ) into all of its permissible
>>> flag-a? ( flagb !flagc !flagd ) variants is a royal pain.
>>> Plus there's readability/understandability to consider here.
>>> 
>> 
>> err, flaga? ( !flagb !flagc !flagd )  i mean..
> 
> It is indeed longer (n flags to roughly n² flags expanded i'd
> say), but i disagree on the readability: i find it much more
> readable as "if flaga is enabled then flagb, flagc and flagd must
> be disabled" etc. which express clearly the preference than
> "exactly one of flaga flagb flagc flagd except if there is a
> problem then flaga but not the others".
> 
> Also, there's something we've overseen with the +/- syntax: What
> about "^^ ( +flaga -flagb -flagc -flagd )" with USE="-flaga flagb
> flagc" ? The only way to solve it would be USE="flaga -flagb
> -flagc" while the "implication syntax" could give you USE="-flaga
> flagb -flagc" (or any other preference of the ebuild writer).
> 

I don't think we've overseen that.  If there's a conflict due to any
two flags being set in ^^ ( +a b c d ), the default resolution is to
enable a and disable b,c,d.  Doesn't matter if a is one of the ones
enabled or not.

If you want to try and roll out the syntax, such that for any
particular given set of flags being enabled there is a preferable
default, then yes it'll have to be written out longhand for sure.

OR we could just adjust PMS to assume flag order determines
precedence and still not bother with a new operator:  For "^^ ( a b
c )" if a then b,c forced-off; elif b then c forced-off; elif !c
then a forced-on; fi



> Finally, about getting the logic right, since it's a subset of
> the current syntax I don't think that should be a problem :)

The superset of the "{,!}flag1? ( {,!}flag2 )" syntax was requested
and created I believe -because- dev's were finding it
difficult/annoying to write the logic out longhand and get it right.
 AND it made the messages a lot more clear to end-users too, as I
recall, as "only-one-of ( flagset )" is a lot more clear and concise
than "flag1-enabled so must-enable/disable-the-rest-in-flagset."  I
didn't pay that much attention at the time though so if anyone
involved with those operator requests etc could chime in on
reasoning I'd appreciate it.



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

iF4EAREIAAYFAlXLhMkACgkQAJxUfCtlWe2A3wEA0jrf9slDrcM92yhXpGpTzBbD
baQAYRUrJsNEI+frKx4BAM9gWVbmGr6U9KAwBdzUVkOFUmZmFj9h7BHFdDsniI1t
=7UNL
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 13:39:21 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/08/15 01:22 PM, Alexis Ballier wrote:
> > On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius
> > <axs@gentoo.org> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >> 
> >> On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
> >>> On 12/08/15 01:00 PM, Alexis Ballier wrote:
> >>>> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius 
> >>>> <axs@gentoo.org> wrote:
> >>> 
> >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>>>> 
> >>>>> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
> >>>>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
> >>>>>>> 2 - is there a particular reasoning for the - in
> >>>>>>> front of qt4 here? I only ask because it would seem
> >>>>>>> that a single default-enable should suffice in lists
> >>>>>>> like this to indicate a resolution path, no? That is,
> >>>>>>> '^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like
> >>>>>>> it would be the same as '^^ ( +flag1 flag2 flag3
> >>>>>>> flag4 )'
> >>>>>> 
> >>>>>> If the user has both "qt4 qt5", then enabling qt5 alone
> >>>>>>  won't help to resolve "^^ ( qt5 qt4 )".
> >>>>>> 
> >>>>> 
> >>>>> Right, but the PM knows based on a particular
> >>>>> REQUIRED_USE operator what it would need to do when a
> >>>>> particular flag is set to default. Given '^^' is
> >>>>> must-be-one-of, the +flag would be enabled and all the
> >>>>> other flags would be disabled, right?
> >>>>> 
> >>>>> Here's how I'd see it mapping out:
> >>>>> 
> >>>>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ ( 
> >>>>> +flag1 flag2 ... ) , PM forces-on flag1, forces-off all 
> >>>>> others ?? ( +flag2 flag2 ... ) , PM forces off all but
> >>>>> flag1
> >>>>> 
> >>>>> I'm not sure if the following make sense though...
> >>>>> thoughts?
> >>>>> 
> >>>>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? ( 
> >>>>> +!flag2 ) , PM forces !flag2, meaning forces-off flag2
> >>>>> 
> >>>>> 
> >>>>> I'm just wondering if it's really necessary in terms of 
> >>>>> syntax to specify the flag-negation that the PM would
> >>>>> need to do.
> >>> 
> >>> 
> >>>> See my other email: neither + nor - are necessary :)
> >>> 
> >>> 
> >>> 
> >>> 
> >>> I'd disagree on that -- technically they aren't necessary,
> >>> but the whole reason why these new operators were added in
> >>> the first place was so that it's a lot easier for developers
> >>> to fill in REQUIRED_USE and get the logic right.  Mapping out
> >>> a ^^ ( flag1 flag2 flag3 flag4 ) into all of its permissible
> >>> flag-a? ( flagb !flagc !flagd ) variants is a royal pain.
> >>> Plus there's readability/understandability to consider here.
> >>> 
> >> 
> >> err, flaga? ( !flagb !flagc !flagd )  i mean..
> > 
> > It is indeed longer (n flags to roughly n² flags expanded i'd
> > say), but i disagree on the readability: i find it much more
> > readable as "if flaga is enabled then flagb, flagc and flagd must
> > be disabled" etc. which express clearly the preference than
> > "exactly one of flaga flagb flagc flagd except if there is a
> > problem then flaga but not the others".
> > 
> > Also, there's something we've overseen with the +/- syntax: What
> > about "^^ ( +flaga -flagb -flagc -flagd )" with USE="-flaga flagb
> > flagc" ? The only way to solve it would be USE="flaga -flagb
> > -flagc" while the "implication syntax" could give you USE="-flaga
> > flagb -flagc" (or any other preference of the ebuild writer).
> > 
> 
> I don't think we've overseen that.  If there's a conflict due to any
> two flags being set in ^^ ( +a b c d ), the default resolution is to
> enable a and disable b,c,d.  Doesn't matter if a is one of the ones
> enabled or not.
> 
> If you want to try and roll out the syntax, such that for any
> particular given set of flags being enabled there is a preferable
> default, then yes it'll have to be written out longhand for sure.
> 
> OR we could just adjust PMS to assume flag order determines
> precedence and still not bother with a new operator:  For "^^ ( a b
> c )" if a then b,c forced-off; elif b then c forced-off; elif !c
> then a forced-on; fi

that's another possible option indeed

> > Finally, about getting the logic right, since it's a subset of
> > the current syntax I don't think that should be a problem :)
> 
> The superset of the "{,!}flag1? ( {,!}flag2 )" syntax was requested
> and created I believe -because- dev's were finding it
> difficult/annoying to write the logic out longhand and get it right.


:)

I'd rather bet it's been copied from what we're used to: license & dep
strings.


>  AND it made the messages a lot more clear to end-users too, as I
> recall, as "only-one-of ( flagset )" is a lot more clear and concise
> than "flag1-enabled so must-enable/disable-the-rest-in-flagset."  I
> didn't pay that much attention at the time though so if anyone
> involved with those operator requests etc could chime in on
> reasoning I'd appreciate it.

I think autounmask-write is much more clear than any kind of error
message

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 01:52 PM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 13:39:21 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
>> 
>> ...OR we could just adjust PMS to assume flag order determines 
>> precedence and still not bother with a new operator:  For "^^ (
>> a b c )" if a then b,c forced-off; elif b then c forced-off;
>> elif !c then a forced-on; fi
> 
> that's another possible option indeed
> 

Is this something that we would need to change PMS for?  Syntax
stays the same, just the way portage (in particular here) acts on it
would be different...  For testing, is what I'm thinking, say tied
to a "resolve-required-use" feature?

If we don't -need- to change PMS we could just -do- this and see if
it works.


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

iF4EAREIAAYFAlXLkhwACgkQAJxUfCtlWe2icgD/fvbn2O70mE2QJs5+mOfxwZEx
Y6huevd2KkJnaEHmlPEBAOvLe3gLDR/KUgvQVytBAXxgu+XsDcN/SDZEt94K0ptE
=ySbZ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 14:36:12 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/08/15 01:52 PM, Alexis Ballier wrote:
> > On Wed, 12 Aug 2015 13:39:21 -0400 Ian Stakenvicius
> > <axs@gentoo.org> wrote:
> >> 
> >> ...OR we could just adjust PMS to assume flag order determines 
> >> precedence and still not bother with a new operator:  For "^^ (
> >> a b c )" if a then b,c forced-off; elif b then c forced-off;
> >> elif !c then a forced-on; fi
> > 
> > that's another possible option indeed
> > 
> 
> Is this something that we would need to change PMS for?  Syntax
> stays the same, just the way portage (in particular here) acts on it
> would be different...  For testing, is what I'm thinking, say tied
> to a "resolve-required-use" feature?
> 
> If we don't -need- to change PMS we could just -do- this and see if
> it works.

we could since that's de facto equivalent to the +/- syntax; however, I
have serious doubts that the outcome will be what people who wrote the
REQUIRED_USE line intended

that'd be a very good proof of concept though

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 17:08:59 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote:
> 
> > i.e. something that really tells the PM how to automate the choice:
> > - 'qt5 -> !qt4' is rather straightforward to solve and tells the PM
> > how (note that it is not equivalent to 'qt4 -> !qt5')
> > - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to
> >   automate it
> 
> I was thinking about some syntax like this:
> 
>    REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"
> 
> The package manager would first evaluate each group in REQUIRED_USE
> with the original set of USE flags. If that doesn't evaluate to true,
> retry with flags changed as indicated by the + and - signs.


it is more in the line of what we currently do, but that doesn't
resolve the 'sat' problem: it doesnt make clear we don't want to
satisfy it but rather walk through a list of causes and consequences

now that i'm thinking more about it, killing || and ^^ would probably
solve the automation problem:
qt? ( !qt4? ( qt5 ) qt4? ( !qt5 ) ) vs 'qt? ( ^^ ( qt4 qt5 ) )'

a bit longer but PM now knows what to do


both are equally expressive:

|| ( a b ) <-> !a? ( b )
(or !b? ( a ) depending on preference)
Here PM will enable b if a is disabled (a if b is disabled in the
latter form)

^^ ( a b ) <-> !a? ( b ) a? ( !b )
Here PM will enable b if a is disabled; disable b if a is enabled


No need for a new syntax :)

Alexis.

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Wed, 12 Aug 2015 17:08:59 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote:
> > i.e. something that really tells the PM how to automate the choice:
> > - 'qt5 -> !qt4' is rather straightforward to solve and tells the PM
> > how (note that it is not equivalent to 'qt4 -> !qt5')
> > - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to
> >   automate it
> 
> I was thinking about some syntax like this:
> 
>    REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"
> 
> The package manager would first evaluate each group in REQUIRED_USE
> with the original set of USE flags. If that doesn't evaluate to true,
> retry with flags changed as indicated by the + and - signs.

The problem with REQUIRED_USE was someone having an idea and not
implementing it and trying it out before inflicting it upon people. Why
not start with a test implementation?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Michael Orlitzky]

On 08/12/2015 12:21 AM, Ciaran McCreesh wrote:
> On Tue, 11 Aug 2015 23:30:31 +1000
> Michael Palimaka <kensington@gentoo.org> wrote:
>> I invite you to reproduce the problem yourself then make the
>> judgement. Using REQUIRED_USE like this makes the affected packages
>> unusable.
> 
> Can't we all (except for the usual suspect) just agree that REQUIRED_USE
> was a mistake, and go back to pkg_pretend? The only justification for
> REQUIRED_USE was that it could allegedly be used in an automated
> fashion, and this hasn't happened.
> 

I'm starting to see the light. USE flags and their
combinations/conflicts are almost always package- if not
ebuild-specific. The problem isn't that REQUIRED_USE forces me to do
something, it's that portage will only ever be able to output 45 pages
of garbage rather than telling me how to fix it (which again, depends on
the package/ebuild).

At the very least, we need to be able to tag REQUIRED_USE conflicts with
human readable error messages. OK, so I know I can't have USE="qt4 qt5"
for this package... but why? How do I fix it? We can do that with
pkg_pretend and a bunch of "if" statements, or maybe there's value in
having the requirements in a variable -- who knows. The former is a lot
simpler to implement.

Re: [gentoo-dev] Re: useflag policies

[William Hubbs]

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

On Wed, Aug 12, 2015 at 09:40:00AM -0400, Michael Orlitzky wrote:
> On 08/12/2015 12:21 AM, Ciaran McCreesh wrote:
> > On Tue, 11 Aug 2015 23:30:31 +1000
> > Michael Palimaka <kensington@gentoo.org> wrote:
> >> I invite you to reproduce the problem yourself then make the
> >> judgement. Using REQUIRED_USE like this makes the affected packages
> >> unusable.
> > 
> > Can't we all (except for the usual suspect) just agree that REQUIRED_USE
> > was a mistake, and go back to pkg_pretend? The only justification for
> > REQUIRED_USE was that it could allegedly be used in an automated
> > fashion, and this hasn't happened.
> > 
> 
> I'm starting to see the light. USE flags and their
> combinations/conflicts are almost always package- if not
> ebuild-specific. The problem isn't that REQUIRED_USE forces me to do
> something, it's that portage will only ever be able to output 45 pages
> of garbage rather than telling me how to fix it (which again, depends on
> the package/ebuild).
> 
> At the very least, we need to be able to tag REQUIRED_USE conflicts with
> human readable error messages. OK, so I know I can't have USE="qt4 qt5"
> for this package... but why? How do I fix it? We can do that with
> pkg_pretend and a bunch of "if" statements, or maybe there's value in
> having the requirements in a variable -- who knows. The former is a lot
> simpler to implement.

I always wondered why pkg_pretend never caught on.

I to can see the advantage of it over REQUIRED_USE; it would allow the
package maintainer to give specific error messages about why use flag
combinations are invalid for a package.

Without really knowing what the opposing viewpoint is, I think
pkg_pretend is the better way to go as well.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Wed, 12 Aug 2015 09:38:19 -0500
William Hubbs <williamh@gentoo.org> wrote:
> I always wondered why pkg_pretend never caught on.
> 
> I to can see the advantage of it over REQUIRED_USE; it would allow the
> package maintainer to give specific error messages about why use flag
> combinations are invalid for a package.
> 
> Without really knowing what the opposing viewpoint is, I think
> pkg_pretend is the better way to go as well.

The opposing viewpoint was ferringb believing he could do "automatic
dependency resolution" for a build server setup, without trying it and
without an implementation, and that a human-readable pkg_pretend would
somehow preclude that.

(Incidentally, Exherbo has automatic dependency resolution for a build
server setup, and human-readable messages, and it got there by trying
stuff out before inflicting it upon everyone by diktat...)

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:

> The opposing viewpoint was ferringb believing he could do "automatic
> dependency resolution" for a build server setup, without trying it
> and without an implementation, and that a human-readable pkg_pretend
> would somehow preclude that.

Hm, how about adding a new PM command like "required_use foo -bar"?
It would be used exclusively in pkg_pretend, and tell the PM to
suggest the necessary package.use changes to the user (or even update
them automatically with the appropriate --autounmask-* option).

REQUIRED_USE could be banned at the same time.

Ulrich

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

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Wed, 12 Aug 2015 19:38:21 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> > The opposing viewpoint was ferringb believing he could do "automatic
> > dependency resolution" for a build server setup, without trying it
> > and without an implementation, and that a human-readable pkg_pretend
> > would somehow preclude that.
> 
> Hm, how about adding a new PM command like "required_use foo -bar"?
> It would be used exclusively in pkg_pretend, and tell the PM to
> suggest the necessary package.use changes to the user (or even update
> them automatically with the appropriate --autounmask-* option).
> 
> REQUIRED_USE could be banned at the same time.

Why add support for a hypothetical package mangler feature that doesn't
exist and that isn't necessary in practice?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Wed, 12 Aug 2015, Ulrich Mueller wrote:

> Hm, how about adding a new PM command like "required_use foo -bar"?
> It would be used exclusively in pkg_pretend, and tell the PM to
> suggest the necessary package.use changes to the user (or even update
> them automatically with the appropriate --autounmask-* option).

To clarify, I'm thinking about something like this:

pkg_pretend() {
    if use qt4; then
        required_use -qt5
    else
        required_use qt5
    fi
}

The advantage would be that any number of elog messages could be added
which would further explain things to the user.

Ulrich

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

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Wed, 12 Aug 2015 19:43:55 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Wed, 12 Aug 2015, Ulrich Mueller wrote:
> > Hm, how about adding a new PM command like "required_use foo -bar"?
> > It would be used exclusively in pkg_pretend, and tell the PM to
> > suggest the necessary package.use changes to the user (or even
> > update them automatically with the appropriate --autounmask-*
> > option).
> 
> To clarify, I'm thinking about something like this:
> 
> pkg_pretend() {
>     if use qt4; then
>         required_use -qt5
>     else
>         required_use qt5
>     fi
> }
> 
> The advantage would be that any number of elog messages could be added
> which would further explain things to the user.

And how would the PM understand that -qt5 is conditional upon qt4? Such
knowledge is required if it's supposed to auto-resolve stuff...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:

>> pkg_pretend() {
>>     if use qt4; then
>>         required_use -qt5
>>     else
>>         required_use qt5
>>     fi
>> }

> And how would the PM understand that -qt5 is conditional upon qt4?
> Such knowledge is required if it's supposed to auto-resolve stuff...

Right, the above was too simple (and wrong). It should have been:

pkg_pretend() {
    use qt4 && use qt5 && required_use -qt5
    use qt4 || use qt5 || required_use qt4
}

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

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Wed, 12 Aug 2015 20:00:42 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> >> pkg_pretend() {
> >>     if use qt4; then
> >>         required_use -qt5
> >>     else
> >>         required_use qt5
> >>     fi
> >> }
> 
> > And how would the PM understand that -qt5 is conditional upon qt4?
> > Such knowledge is required if it's supposed to auto-resolve stuff...
> 
> Right, the above was too simple (and wrong). It should have been:
> 
> pkg_pretend() {
>     use qt4 && use qt5 && required_use -qt5
>     use qt4 || use qt5 || required_use qt4
> }

Doesn't help the PM, unless you're expecting it to parse bash code...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 02:00 PM, Ulrich Mueller wrote:
>>>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> 
>>> pkg_pretend() { if use qt4; then required_use -qt5 else 
>>> required_use qt5 fi }
> 
>> And how would the PM understand that -qt5 is conditional upon
>> qt4? Such knowledge is required if it's supposed to
>> auto-resolve stuff...
> 
> Right, the above was too simple (and wrong). It should have
> been:
> 
> pkg_pretend() { use qt4 && use qt5 && required_use -qt5 use qt4
> || use qt5 || required_use qt4 }
> 

I think Ciaran's point was more, if required_use is going to i.e.
elog, it needs to elog that qt4 is being enabled because neither-of
qt4 or qt5 are off, and similarly for why qt5 is being disabled.


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

iF4EAREIAAYFAlXLjdwACgkQAJxUfCtlWe3K6QD+L3kdVxSIJDp3N+wBZEtuhtNT
5kT7NXTdXuubE4Dgv7wA/1auz4k+rYQDZP7DP+i/JsHA/RMhOgUt7yc5a0H8yYHS
=FXa+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 02:18 PM, Ian Stakenvicius wrote:
> On 12/08/15 02:00 PM, Ulrich Mueller wrote:
>>>>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> 
>>>> pkg_pretend() { if use qt4; then required_use -qt5 else 
>>>> required_use qt5 fi }
> 
>>> And how would the PM understand that -qt5 is conditional
>>> upon qt4? Such knowledge is required if it's supposed to 
>>> auto-resolve stuff...
> 
>> Right, the above was too simple (and wrong). It should have 
>> been:
> 
>> pkg_pretend() { use qt4 && use qt5 && required_use -qt5 use
>> qt4 || use qt5 || required_use qt4 }
> 
> 
> I think Ciaran's point was more, if required_use is going to
> i.e. elog, it needs to elog that qt4 is being enabled because
> neither-of qt4 or qt5 are *ON*, and similarly for why qt5 is
> being disabled.

^^^ corrected logic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXLjh8ACgkQAJxUfCtlWe3TTAEAuJPVQQ9yoWBeBTRH2AFnFZoW
3aWWdhmClQRMo3MI43IBANkaRZOtWHhnWi31wvK+Pw0GvzkAmzEaWOFS7YxxWORO
=ccVT
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 20:00:42 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> 
> >> pkg_pretend() {
> >>     if use qt4; then
> >>         required_use -qt5
> >>     else
> >>         required_use qt5
> >>     fi
> >> }
> 
> > And how would the PM understand that -qt5 is conditional upon qt4?
> > Such knowledge is required if it's supposed to auto-resolve stuff...
> 
> Right, the above was too simple (and wrong). It should have been:
> 
> pkg_pretend() {
>     use qt4 && use qt5 && required_use -qt5
>     use qt4 || use qt5 || required_use qt4
> }

what is the difference ?

pkg_pretend still needs to be executed to guess what useflags are
enabled or not, which information is needed before dependency
calculation

or are we talking about moving pkg_pretend into dependency calculation?

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 02:19 PM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 20:00:42 +0200 Ulrich Mueller
> <ulm@gentoo.org> wrote:
> 
>>>>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
>> 
>>>> pkg_pretend() { if use qt4; then required_use -qt5 else 
>>>> required_use qt5 fi }
>> 
>>> And how would the PM understand that -qt5 is conditional upon
>>> qt4? Such knowledge is required if it's supposed to
>>> auto-resolve stuff...
>> 
>> Right, the above was too simple (and wrong). It should have
>> been:
>> 
>> pkg_pretend() { use qt4 && use qt5 && required_use -qt5 use qt4
>> || use qt5 || required_use qt4 }
> 
> what is the difference ?
> 
> pkg_pretend still needs to be executed to guess what useflags
> are enabled or not, which information is needed before
> dependency calculation
> 
> or are we talking about moving pkg_pretend into dependency
> calculation?
> 


pkg_pretend is already executed during dependency calculation in
portage, although this doesn't seem to actually be specified in PMS:
"The pkg_pretend function is called some unspecified time before a
(possibly hypothetical) normal sequence." as per PMS sec.9.2


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

iF4EAREIAAYFAlXLj0YACgkQAJxUfCtlWe1NwgD/UlFiaP1Xyh4yfHlEH+nGIYN/
NTqMi1IFiKXpgKJjVWEA/1BdSHkivkFhodChHJ0jlYCX9xHg0Xc0VDzPN0S1aPRn
=KQmI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 14:24:06 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/08/15 02:19 PM, Alexis Ballier wrote:
> > On Wed, 12 Aug 2015 20:00:42 +0200 Ulrich Mueller
> > <ulm@gentoo.org> wrote:
> > 
> >>>>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> >> 
> >>>> pkg_pretend() { if use qt4; then required_use -qt5 else 
> >>>> required_use qt5 fi }
> >> 
> >>> And how would the PM understand that -qt5 is conditional upon
> >>> qt4? Such knowledge is required if it's supposed to
> >>> auto-resolve stuff...
> >> 
> >> Right, the above was too simple (and wrong). It should have
> >> been:
> >> 
> >> pkg_pretend() { use qt4 && use qt5 && required_use -qt5 use qt4
> >> || use qt5 || required_use qt4 }
> > 
> > what is the difference ?
> > 
> > pkg_pretend still needs to be executed to guess what useflags
> > are enabled or not, which information is needed before
> > dependency calculation
> > 
> > or are we talking about moving pkg_pretend into dependency
> > calculation?
> > 
> 
> 
> pkg_pretend is already executed during dependency calculation in
> portage, although this doesn't seem to actually be specified in PMS:
> "The pkg_pretend function is called some unspecified time before a
> (possibly hypothetical) normal sequence." as per PMS sec.9.2
> 

that's definitely not the impression I've got with emerge -uDNa world:
dep calculation, show result, wait for input, accept, and then
pkg_pretend stuff gets executed.

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 03:15 PM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 14:24:06 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 12/08/15 02:19 PM, Alexis Ballier wrote:
>>> On Wed, 12 Aug 2015 20:00:42 +0200 Ulrich Mueller 
>>> <ulm@gentoo.org> wrote:
>>> 
>>>>>>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
>>>> 
>>>>>> pkg_pretend() { if use qt4; then required_use -qt5 else
>>>>>>  required_use qt5 fi }
>>>> 
>>>>> And how would the PM understand that -qt5 is conditional
>>>>> upon qt4? Such knowledge is required if it's supposed to 
>>>>> auto-resolve stuff...
>>>> 
>>>> Right, the above was too simple (and wrong). It should
>>>> have been:
>>>> 
>>>> pkg_pretend() { use qt4 && use qt5 && required_use -qt5 use
>>>> qt4 || use qt5 || required_use qt4 }
>>> 
>>> what is the difference ?
>>> 
>>> pkg_pretend still needs to be executed to guess what
>>> useflags are enabled or not, which information is needed
>>> before dependency calculation
>>> 
>>> or are we talking about moving pkg_pretend into dependency 
>>> calculation?
>>> 
>> 
>> 
>> pkg_pretend is already executed during dependency calculation
>> in portage, although this doesn't seem to actually be specified
>> in PMS: "The pkg_pretend function is called some unspecified
>> time before a (possibly hypothetical) normal sequence." as per
>> PMS sec.9.2
>> 
> 
> that's definitely not the impression I've got with emerge -uDNa
> world: dep calculation, show result, wait for input, accept, and
> then pkg_pretend stuff gets executed.
> 

Apologies if I'm wrong on that; i'm rather sleep deprived and i
didn't actually check an emerge -uDN before I posted.  I was sure i
saw the "checking for sufficient space" messages show up during the
dependency-calcs though.

Regardless, the role and point of execution of pkg_pretend would
definitely need to be clarified in PMS as yes we would be talking
about ensuring it happens at a specific point in the dependency
calculation process for each package.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXLnIEACgkQAJxUfCtlWe1RpQD9H0WKWDdl7tVHj6KgOoOHPswT
kPQQ0GFadfeo/isbxesBAIEL24JrVyzAEDY2KrofwYe+OVE3LV71jwMpnaGIBAHL
=AMxp
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Wed, 12 Aug 2015 20:19:08 +0200
Alexis Ballier <aballier@gentoo.org> wrote:
> pkg_pretend still needs to be executed to guess what useflags are
> enabled or not, which information is needed before dependency
> calculation

You'd probably be implementing this in a "SAT modulo theories" kind of
way: find a solution, do the pkg_pretend checks, and if it fails spit a
nogood back into the resolver.

But this entire discussion is pointless, since Portage doesn't and
won't auto-resolve this stuff.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 19:25:37 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 12 Aug 2015 20:19:08 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> > pkg_pretend still needs to be executed to guess what useflags are
> > enabled or not, which information is needed before dependency
> > calculation
> 
> You'd probably be implementing this in a "SAT modulo theories" kind of
> way: find a solution, do the pkg_pretend checks, and if it fails spit
> a nogood back into the resolver.
> 
> But this entire discussion is pointless, since Portage doesn't and
> won't auto-resolve this stuff.

considering its speed (at least for portage) and the complexity of the
thing, running the dep solver N times, where N is probably unbounded
doesn't seem benefical at all

esp. since a modified REQUIRED_USE can achieve the same

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Wed, 12 Aug 2015 21:22:48 +0200
Alexis Ballier <aballier@gentoo.org> wrote:
> On Wed, 12 Aug 2015 19:25:37 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Wed, 12 Aug 2015 20:19:08 +0200
> > Alexis Ballier <aballier@gentoo.org> wrote:
> > > pkg_pretend still needs to be executed to guess what useflags are
> > > enabled or not, which information is needed before dependency
> > > calculation
> > 
> > You'd probably be implementing this in a "SAT modulo theories" kind
> > of way: find a solution, do the pkg_pretend checks, and if it fails
> > spit a nogood back into the resolver.
> > 
> > But this entire discussion is pointless, since Portage doesn't and
> > won't auto-resolve this stuff.
> 
> considering its speed (at least for portage) and the complexity of the
> thing, running the dep solver N times, where N is probably unbounded
> doesn't seem benefical at all
> 
> esp. since a modified REQUIRED_USE can achieve the same

But you'd be running it N times to fix a REQUIRED_USE problem anyway.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 01:50 PM, Ciaran McCreesh wrote:
> On Wed, 12 Aug 2015 19:43:55 +0200 Ulrich Mueller
> <ulm@gentoo.org> wrote:
>>>>>>> On Wed, 12 Aug 2015, Ulrich Mueller wrote:
>>> Hm, how about adding a new PM command like "required_use foo
>>> -bar"? It would be used exclusively in pkg_pretend, and tell
>>> the PM to suggest the necessary package.use changes to the
>>> user (or even update them automatically with the appropriate
>>> --autounmask-* option).
>> 
>> To clarify, I'm thinking about something like this:
>> 
>> pkg_pretend() { if use qt4; then required_use -qt5 else 
>> required_use qt5 fi }
>> 
>> The advantage would be that any number of elog messages could
>> be added which would further explain things to the user.
> 
> And how would the PM understand that -qt5 is conditional upon
> qt4? Such knowledge is required if it's supposed to auto-resolve
> stuff...
> 

I don't think required_use could auto-resolve here, without some
other rather large changes to PMs -- for instance, the spec
pkg_pretend likely needs to be assured to be taken into account
before dependency resolution of that package somehow.

Also, the required_use function needs to be permitted to modify
effective-use and/or do whatever else it does, meaning that for what
I believe is the first time we will have function calls in ebuilds
modifying the precursors to dependency resolution dynamically rather
than it being deterministic based on state and pre-defined static
logic.  (i hope that makes sense, unsure if i'm using anything even
close to the correct terminology)


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

iF4EAREIAAYFAlXLjWcACgkQAJxUfCtlWe2eDwEAzIcJWKlyFVbKzRCWIYEzP+JX
DxdOOgnWd9IVfVdwAqQBAOQaJuXjPPpahfyq0qGQDjX6YKhGY2M2b/D/LjIV81HW
=oko+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 01:38 PM, Ulrich Mueller wrote:
>>>>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> 
>> The opposing viewpoint was ferringb believing he could do
>> "automatic dependency resolution" for a build server setup,
>> without trying it and without an implementation, and that a
>> human-readable pkg_pretend would somehow preclude that.
> 
> Hm, how about adding a new PM command like "required_use foo
> -bar"? It would be used exclusively in pkg_pretend, and tell the
> PM to suggest the necessary package.use changes to the user (or
> even update them automatically with the appropriate
> --autounmask-* option).
> 
> REQUIRED_USE could be banned at the same time.
> 
> Ulrich
> 

That's an interesting idea....  from the PM perspective do we have
any functions that can directly affect deptree calculations now?
Crossing that line is the only thing I forsee right now as being the
main issue with this one.

Would the 'required_use' function just suggest/set/force the
necessary change or would it perform the logic too?  ie, would we
just call 'required_use foo -bar', or would we: 'if use foo && use
bar ; then required_use foo -bar ; fi' ?


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

iF4EAREIAAYFAlXLhpgACgkQAJxUfCtlWe0bXwEAtDn5LL2VE0xBJqVxQ193kPeo
Wn8sm6ud5YgUA2hJkBMA/0IDzi4hg7UZsnqdw59m/DGiYE6Devlfo4LoactUVpDD
=4bED
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Patrick Lauer]

On 08/12/15 22:38, William Hubbs wrote:

> I always wondered why pkg_pretend never caught on.

Because, in a way, it triggers at the wrong point of the merge.

emerge -pv fnurk => dependencies look ok

emerge fnurk => pkg_pretend bails out ... eh?!

(This would be a little bit confusing, if not actively hostile, and
useflags + required_use are a lot more 'natural' to the emerge workflow)

> I to can see the advantage of it over REQUIRED_USE; it would allow the
> package maintainer to give specific error messages about why use flag
> combinations are invalid for a package.

And now someone will say "annotations". Sigh.


have fun,

Patrick

Re: [gentoo-dev] Re: useflag policies

[Zac Medico]

On 08/12/2015 05:44 PM, Patrick Lauer wrote:
> On 08/12/15 22:38, William Hubbs wrote:
> 
>> I always wondered why pkg_pretend never caught on.
> 
> Because, in a way, it triggers at the wrong point of the merge.
> 
> emerge -pv fnurk => dependencies look ok
> 
> emerge fnurk => pkg_pretend bails out ... eh?!
> 
> (This would be a little bit confusing, if not actively hostile, and
> useflags + required_use are a lot more 'natural' to the emerge workflow)

The nice thing about REQUIRED_USE is that it is math expression, and
math is a sort of universal language. It leads to uniform error
messages. You can imagine that pkg_pretend messages will tend to be much
less uniform!

>> I to can see the advantage of it over REQUIRED_USE; it would allow the
>> package maintainer to give specific error messages about why use flag
>> combinations are invalid for a package.
> 
> And now someone will say "annotations". Sigh.

Well, nothing stops people from using pkg_pretend to create fancy error
messages now!

> 
> 
> have fun,
> 
> Patrick
> 
> 


-- 
Thanks,
Zac

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

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

On Thu, 13 Aug 2015 08:44:58 +0800
Patrick Lauer <patrick@gentoo.org> wrote:
> On 08/12/15 22:38, William Hubbs wrote:
> > I always wondered why pkg_pretend never caught on.
> 
> Because, in a way, it triggers at the wrong point of the merge.
> 
> emerge -pv fnurk => dependencies look ok
> 
> emerge fnurk => pkg_pretend bails out ... eh?!
> 
> (This would be a little bit confusing, if not actively hostile, and
> useflags + required_use are a lot more 'natural' to the emerge
> workflow)

Uh, the point of the 'pretend' bit in the name is that it *is* run when
you do emerge -p.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: useflag policies

[Kent Fredric]

On 14 August 2015 at 05:37, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> Uh, the point of the 'pretend' bit in the name is that it *is* run when
> you do emerge -p.


It is strange really.

It does them *after* prompting "yes" with --ask

Whats the point of that?

Granted they are very slow for me now with the KDE5 stuff having
virtually every package doing pkg_pretend, so I see why avoiding them
before the --ask might be beneficial.

But I'm not sure how beneficial it is to give me a merge plan, ask me
if I want to do it or not .... and then find out some use flags are
unworkable *after* pressing yes.

( I recently filed bugs on quite a few python packages because they
were being resolved in pkg_pretend when they could have been resolved
in REQUIRED_USE )

Maybe if we could fix *this* wart about pkg_pretend, it would be more
viable as a competitor to REQUIRED_USE ?

-- 
Kent

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

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 12/08/15 09:40 AM, Michael Orlitzky wrote:
> At the very least, we need to be able to tag REQUIRED_USE
> conflicts with human readable error messages. OK, so I know I
> can't have USE="qt4 qt5" for this package... but why? How do I
> fix it? We can do that with pkg_pretend and a bunch of "if"
> statements, or maybe there's value in having the requirements in
> a variable -- who knows. The former is a lot simpler to
> implement.
> 
> 

I still think it's really important to note the meaning of "Can't"
here.  "Can't" IMO should still really mean cannot -- that setting
both flags is going to cause a problem that'll break the system,
conflicts that will cause things to not work.   This whole qt4/qt5
discussion isn't about "can't", but about "doesn't."


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

iF4EAREIAAYFAlXLWoAACgkQAJxUfCtlWe2GAwD/dgkq8Iyd4njMd2tAvO8zWVOr
JddKwKnUxMxT4haGYDYBAIxIQbT5BM3+iHkNWXF8nKm6GXukNKqUODhZl3eNRoUi
=kAZd
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Kent Fredric]

On 12 August 2015 at 16:21, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> Can't we all (except for the usual suspect) just agree that REQUIRED_USE
> was a mistake, and go back to pkg_pretend? The only justification for
> REQUIRED_USE was that it could allegedly be used in an automated
> fashion, and this hasn't happened.


I think such a proposal needs to be tested on places where it is used
heavily, for instance, python modules where REQUIRED_USE is employed
extensively, which could mean a significant number of pkg_pretend
phases executing, which *could* be more expensive than the equivalent
static dependency code.

( And it could be required that python eclass consumers would all have
to provide a pkg_pretend() even if they didn't need required_use
behaviour )

I'm not saying it *is*, but a side by side comparison of real-world
problems there would be important.

( Maybe the complex dependency resolver stuff is much slower, hard to tell )


-- 
Kent

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

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 11/08/15 08:58 AM, Sergey Popov wrote:
> 11.08.2015 15:30, Michael Palimaka пишет:
>> On 11/08/15 20:10, Sergey Popov wrote:
>>> Err, i have read the whole thread and still does not get a
>>> point, why i am wrong.
>> 
>> You clearly have not. The reasoning behind Qt team's policy is
>> described on the page and has been reiterated on this list. You
>> are undermining what little confidence there is in the QA team by
>> making decisions with no consultation about problems you do not
>> understand.
>> 
>>> It's old battle like we have beforce with "gtk" meaning "any
>>> versions of GTK flag". This behaviour should be killed with
>>> fire.
>>> 
>>> Let's me reiterate some of the cases:
>>> 
>>> 1. Package can be build without Qt GUI at all, but either Qt4
>>> or Qt5 can be chosen, but not both.
>>> 
>>> Fix this with REQUIRED_USE, do not enable any of Qt flags by
>>> default
>> 
>> Problem: this requires manual intervention if the user has both
>> qt4 and qt5 USE flags enabled.
>> 
> 
> User choice of using USE flags is NOT a problem
> 
>>> 
>>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5
>>> is required, but not both
>>> 
>>> Same thing here, different REQUIRED_USE operator. But - enable
>>> one of the flags by default to ease life of users.
>> 
>> Problem: this requires manual intervention if the user has both
>> qt4 and qt5 USE flags enabled.
> 
> Same here
> 
>>> 
>>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME
>>> TIME(if such package even exists?)
>>> 
>>> Do not use REQUIRED_USE here, not needed.
>>> 
>>> Now, please tell me, where am i wrong?
>>> 
>> 
>> The problem is manual intervention is required if the user has
>> both qt4 and qt5 USE flags enabled - and this is a common
>> configuration. It is not acceptable to make a user manually add
>> numerous package.use entries when all they want to do is install
>> KDE.
> 
> And here
> 
>> I agree Qt's policy is not a perfect solution, but in the absence
>> of some feature allowing a preference to be set when there is a
>> conflict it's the best we've got.
>> 
> 
> If you want to go this way, then please provide helper functions
> in eclasses to set dependencies properly for all common use cases.
> That will ease life both of developers and users.
> 

Why do you need this?

#1, if you really want RDEPEND to only include the deps the package
will actually use, then you do this:

old:

qt5? ( list of qt5 atoms )
qt4? ( list of qt4 atoms )

..to new:

qt5? ( list of qt5 atoms )
!qt5? (
  qt4? ( list of qt4 atoms )
)


BUT I would advise against this.  If a user has specified both qt4 and
qt5 in USE, then I see no problem with the VDB having both qt4 and qt5
atoms listed as dependencies.  End-users that want a clean VDB can
just make sure they only enable one flag, but end-users that don't
care will have packages that just work.


> Leaving constructing of dependencies to developers in all cases
> will cause only pain in your solution.

It really wont, see above.  At minimum, it's barely any more work than
it is with a REQUIRED_USE based solution.


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

iF4EAREIAAYFAlXKDTkACgkQAJxUfCtlWe09QAD/ST47V7i08k09c8o+dgMx8hQP
cRyBiTzxHKKtQ3aqmKIBAIdjBB4rGZLLMjiu9l0KfUOkOT1J+Z8oHPWQhzDPJpqv
=LCgR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 17:56, Ian Stakenvicius пишет:
> On 11/08/15 08:58 AM, Sergey Popov wrote:
>> 11.08.2015 15:30, Michael Palimaka пишет:
>>> On 11/08/15 20:10, Sergey Popov wrote:
>>>> Err, i have read the whole thread and still does not get a
>>>> point, why i am wrong.
>>>
>>> You clearly have not. The reasoning behind Qt team's policy is
>>> described on the page and has been reiterated on this list. You
>>> are undermining what little confidence there is in the QA team by
>>> making decisions with no consultation about problems you do not
>>> understand.
>>>
>>>> It's old battle like we have beforce with "gtk" meaning "any
>>>> versions of GTK flag". This behaviour should be killed with
>>>> fire.
>>>>
>>>> Let's me reiterate some of the cases:
>>>>
>>>> 1. Package can be build without Qt GUI at all, but either Qt4
>>>> or Qt5 can be chosen, but not both.
>>>>
>>>> Fix this with REQUIRED_USE, do not enable any of Qt flags by
>>>> default
>>>
>>> Problem: this requires manual intervention if the user has both
>>> qt4 and qt5 USE flags enabled.
>>>
> 
>> User choice of using USE flags is NOT a problem
> 
>>>>
>>>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5
>>>> is required, but not both
>>>>
>>>> Same thing here, different REQUIRED_USE operator. But - enable
>>>> one of the flags by default to ease life of users.
>>>
>>> Problem: this requires manual intervention if the user has both
>>> qt4 and qt5 USE flags enabled.
> 
>> Same here
> 
>>>>
>>>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME
>>>> TIME(if such package even exists?)
>>>>
>>>> Do not use REQUIRED_USE here, not needed.
>>>>
>>>> Now, please tell me, where am i wrong?
>>>>
>>>
>>> The problem is manual intervention is required if the user has
>>> both qt4 and qt5 USE flags enabled - and this is a common
>>> configuration. It is not acceptable to make a user manually add
>>> numerous package.use entries when all they want to do is install
>>> KDE.
> 
>> And here
> 
>>> I agree Qt's policy is not a perfect solution, but in the absence
>>> of some feature allowing a preference to be set when there is a
>>> conflict it's the best we've got.
>>>
> 
>> If you want to go this way, then please provide helper functions
>> in eclasses to set dependencies properly for all common use cases.
>> That will ease life both of developers and users.
> 
> 
> Why do you need this?
> 
> #1, if you really want RDEPEND to only include the deps the package
> will actually use, then you do this:
> 
> old:
> 
> qt5? ( list of qt5 atoms )
> qt4? ( list of qt4 atoms )
> 
> ..to new:
> 
> qt5? ( list of qt5 atoms )
> !qt5? (
>   qt4? ( list of qt4 atoms )
> )
> 
> 
> BUT I would advise against this.  If a user has specified both qt4 and
> qt5 in USE, then I see no problem with the VDB having both qt4 and qt5
> atoms listed as dependencies.  End-users that want a clean VDB can
> just make sure they only enable one flag, but end-users that don't
> care will have packages that just work.
> 

great, in that case emerge --depclean becomes completely useless,
because of unneeded vdb deps. Those DEPENDs that i have provided was at
least consistent in terms of dependencies(that does not mean that they
are not ugly, though)

>> Leaving constructing of dependencies to developers in all cases
>> will cause only pain in your solution.
> 
> It really wont, see above.  At minimum, it's barely any more work than
> it is with a REQUIRED_USE based solution.
> 

I repeat that i said earlier: if this voodoo magic will be hidden in
some eclass - it is fine. If developers will be forced to add this
depstring over and over again - it will be PITA.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 13/08/15 04:24 AM, Sergey Popov wrote:
> 11.08.2015 17:56, Ian Stakenvicius пишет:
>> BUT I would advise against this.  If a user has specified both
>> qt4 and qt5 in USE, then I see no problem with the VDB having
>> both qt4 and qt5 atoms listed as dependencies.  End-users that
>> want a clean VDB can just make sure they only enable one flag,
>> but end-users that don't care will have packages that just
>> work.
>> 
> 
> great, in that case emerge --depclean becomes completely
> useless, because of unneeded vdb deps. Those DEPENDs that i have
> provided was at least consistent in terms of dependencies(that
> does not mean that they are not ugly, though)
> 

No it doesn't.  It's true that it doesn't end up providing a
necessarily fully clean system when both flags are enabled, but
there's nothing to keep end-users (or the profiles, when they
change) from disabling the qt4 flag on their own terms to get a
cleaner system.

My entire point here is using the BFH of REQUIRED_USE to force
end-users to take manual action on emerge, just because some dev's
want them to have a cleaner system via --depclean, -especially- when
there aren't any conflicts between the qt4 and qt5 deps being
installed at the same time, is to the detriment of end users much
more than the extra libs in the system image.

If qt4 and qt5 libs collided or conflicted, then this would be a
different story, but they don't.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXMqToACgkQAJxUfCtlWe3tDgEAjPRuf+zAFhYWYNyLefIptPnT
0y3Z2UuOIBO2Bdmqp1oBAJgIMpH5c95dKXkskL/UzvYhgdG4Z8vPDbCjKc/NMZ8g
=j8+H
-----END PGP SIGNATURE-----

[gentoo-dev] Re: useflag policies

[Duncan]

Sergey Popov posted on Tue, 11 Aug 2015 15:58:49 +0300 as excerpted:

> 11.08.2015 15:30, Michael Palimaka пишет:
>> On 11/08/15 20:10, Sergey Popov wrote:
>>> Err, i have read the whole thread and still does not get a point, why
>>> i am wrong.
>> 
>> You clearly have not. The reasoning behind Qt team's policy is
>> described on the page and has been reiterated on this list. You are
>> undermining what little confidence there is in the QA team by making
>> decisions with no consultation about problems you do not understand.
>> 
>>> It's old battle like we have beforce with "gtk" meaning "any versions
>>> of GTK flag". This behaviour should be killed with fire.
>>>
>>> Let's me reiterate some of the cases:
>>>
>>> 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5
>>> can be chosen, but not both.
>>>
>>> Fix this with REQUIRED_USE, do not enable any of Qt flags by default
>> 
>> Problem: this requires manual intervention if the user has both qt4 and
>> qt5 USE flags enabled.
>>
>>
> User choice of using USE flags is NOT a problem

[As has been said elsewhere in the thread but you apparently haven't 
seen...]

But if the profile enables both qt4 and qt5, as at least one profile, the 
new plasma (aka kde5) profile does, and really must?

The desktop profile enables qt4.  The plasma profile inherits qt4 from 
there and enables qt5, so both are enabled.

And because kde5 is an incremental switchover that still includes many 
kde4-based apps, some of which likely have deps that need qt4 in the USE 
flags and users likely still want it enabled in any case, it's not as 
simple as disabling the qt4 USE flag in the plasma profile, either.

Furthermore, as qt5 matures and more apps base on it, it's likely that qt5 
will need enabled in the desktop profile as well, well before qt4 can be 
conveniently disabled.

So there's some users now, the ones using the plasma profile, and will 
soon be very many users, anyone using a desktop-inheriting profile, that 
will have and arguably need, both qt4 and qt5 enabled.

You're really saying that *all* of them should be forced to deal with 
dozens of package-specific package.use settings, to negate the effects of 
REQUIRED_USE when both qt4 and qt5 are enabled in their gentoo-shipped 
profile?

This is why it's a problem.  If it were just the people that specifically 
set both qt4 and qt5 in make.conf. it'd be a much smaller problem and 
could perhaps be simply ignored as a user-created problem.  But when it's 
the default setting in all desktop profiles, as it's very likely to be 
within a year, it's no longer simply a user-created problem.

[Personally, I both run with USE="-* ..." and started trying qt5 and kde5/
plasma back when they were both still in the overlay, so I've long since 
worked out the biggest such problems here.  I didn't complain as it's 
simply part of both trying things that far ahead and specifying that I 
/want/ the choice and will deal with the consequences of such things by 
setting USE=-*.  But it'd be very nice if our stable desktop users didn't 
have to go thru the same thing I did, once they get plasma5, just because 
they use a desktop profile.]

-- 
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: useflag policies

[Ian Stakenvicius]

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

On 11/08/15 06:10 AM, Sergey Popov wrote:
> Err, i have read the whole thread and still does not get a point,
> why i am wrong.
> 
> It's old battle like we have beforce with "gtk" meaning "any
> versions of GTK flag". This behaviour should be killed with fire.
> 
> Let's me reiterate some of the cases:
> 
> 1. Package can be build without Qt GUI at all, but either Qt4 or
> Qt5 can be chosen, but not both.
> 
> Fix this with REQUIRED_USE, do not enable any of Qt flags by
> default
> 


Why does this need REQUIRED_USE at all?  neither flag is necessary,
and just because the package only uses one flag at a time doesn't mean
we should require users that have both flags set in profiles to -have
to- package.use one of them off.



> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is 
> required, but not both
> 
> Same thing here, different REQUIRED_USE operator. But - enable one
> of the flags by default to ease life of users.
> 

IUSE="qt4 +qt5" and USE="qt4 -qt5" globally (ie from profiles) is
going to make a REQUIRED_USE force an exception in package.use as
well.  Again, annoying to end-users for no overly good reason and see #1
.


> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if
> such package even exists?)
> 
> Do not use REQUIRED_USE here, not needed.
> 
> Now, please tell me, where am i wrong?
> 


IMO it's wrong because REQUIRED_USE is a BFH for what really ends up
as an extra, dangling enabled use flag.  Unless there's a case (and i
truely doubt there is) that there's a package with IUSE="qt4" that
depends on ANOTHER package with IUSE="qt4 qt5", and that other package
only builds against one implementation, AND the dep on the first
package doesn't include any use deps, I still see no actual -need- for
REQUIRED_USE.


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

iF4EAREIAAYFAlXKCZwACgkQAJxUfCtlWe3GqwEA2UCV9E+h+Djy7+KiwqODkEjv
MiToijoa6ncX3xicD4cA/3PIQcv3ObG+obxECkB1gzyYclQrVGCaHT79DAkVE3oK
=2iat
-----END PGP SIGNATURE-----

[gentoo-dev] Re: useflag policies

[Ulrich Mueller]

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

>>>>> On Sun, 09 Aug 2015, Sergey Popov wrote:

> <qa team lead hat>
> In short - apropriate REQUIRED_USE with setting recommended
> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")

> </qa team lead hat>

> That's most painless decision for both developers and users. Developers
> do not need to maintain ugly dependencies like

> DEPEND="qt4 ? (
> qt5 ( dev-qt/qtcore:5 )
> !qt5 ( dev-qt/qtcore:4 )
> )
> ...
> "
> and other mess.

> </qa team lead hat>

I disagree with this. Really, REQUIRED_USE should be used sparingly,
and IMHO the above is not a legitimate usage case for it.

Ulrich

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

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

09.08.2015 23:28, Ulrich Mueller пишет:
> I disagree with this. Really, REQUIRED_USE should be used sparingly,
> and IMHO the above is not a legitimate usage case for it.

So, you prefer to make ugly mess of deps here like i posted before or
introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
users even more confused?

Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
And dependency string like this:

!berkdb? ( !gdbm? ( sys-libs/gdbm ) )

One sentence: "WHAT THE HELL?"

Imagine that it would be dozen of flags. Is it fun to mess with deps
like this for you?

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 11/08/15 20:17, Sergey Popov wrote:
> 09.08.2015 23:28, Ulrich Mueller пишет:
>> I disagree with this. Really, REQUIRED_USE should be used sparingly,
>> and IMHO the above is not a legitimate usage case for it.
> 
> So, you prefer to make ugly mess of deps here like i posted before or
> introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
> users even more confused?
> 
> Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
> And dependency string like this:
> 
> !berkdb? ( !gdbm? ( sys-libs/gdbm ) )
> 
> One sentence: "WHAT THE HELL?"
> 
> Imagine that it would be dozen of flags. Is it fun to mess with deps
> like this for you?

Shall we ban this too?

ffmpeg? (
        libav? ( media-video/libav:= )
        !libav? ( media-video/ffmpeg:0= )
)

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 15:32, Michael Palimaka пишет:
> On 11/08/15 20:17, Sergey Popov wrote:
>> 09.08.2015 23:28, Ulrich Mueller пишет:
>>> I disagree with this. Really, REQUIRED_USE should be used sparingly,
>>> and IMHO the above is not a legitimate usage case for it.
>>
>> So, you prefer to make ugly mess of deps here like i posted before or
>> introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
>> users even more confused?
>>
>> Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
>> And dependency string like this:
>>
>> !berkdb? ( !gdbm? ( sys-libs/gdbm ) )
>>
>> One sentence: "WHAT THE HELL?"
>>
>> Imagine that it would be dozen of flags. Is it fun to mess with deps
>> like this for you?
> 
> Shall we ban this too?
> 
> ffmpeg? (
>         libav? ( media-video/libav:= )
>         !libav? ( media-video/ffmpeg:0= )
> )
> 
> 
> 
> 

No, because ffmpeg here is a feature AND name of concrete realization.
Not ideal case as i would said, but it is acceptable.

You want to migrate to such decision? Like:

qt? (
	qt5? ( dev-lang/qtcore:5 )
	!qt5? ( dev-lang/qtcore:4 )
)

Fine by me, if you would ask.

As i said one message earlier: Something like $(qt_use_default qtgui 5)

which will generate something like this:

qt4? (
	qt5? ( dev-lang/qtcore:5 )
	!qt5? ( dev-lang/qtcore:4 )
)
!qt5? ( !qt4? ( dev-lang/qtcore:5 ) )

would help too.

If you are doing complicated things(and please, do not tell me that
provided dependency string is simple and understandable by every
developer in just a second without wanting to "improve" or "simplify"
it) - do it through eclass. And provide nice API.

Thanks for listening and sorry if i was too harsh

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 16:04, Sergey Popov пишет:
> 11.08.2015 15:32, Michael Palimaka пишет:
>> On 11/08/15 20:17, Sergey Popov wrote:
>>> 09.08.2015 23:28, Ulrich Mueller пишет:
>>>> I disagree with this. Really, REQUIRED_USE should be used sparingly,
>>>> and IMHO the above is not a legitimate usage case for it.
>>>
>>> So, you prefer to make ugly mess of deps here like i posted before or
>>> introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
>>> users even more confused?
>>>
>>> Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
>>> And dependency string like this:
>>>
>>> !berkdb? ( !gdbm? ( sys-libs/gdbm ) )
>>>
>>> One sentence: "WHAT THE HELL?"
>>>
>>> Imagine that it would be dozen of flags. Is it fun to mess with deps
>>> like this for you?
>>
>> Shall we ban this too?
>>
>> ffmpeg? (
>>         libav? ( media-video/libav:= )
>>         !libav? ( media-video/ffmpeg:0= )
>> )
>>
>>
>>
>>
> 
> No, because ffmpeg here is a feature AND name of concrete realization.
> Not ideal case as i would said, but it is acceptable.
> 
> You want to migrate to such decision? Like:
> 
> qt? (
> 	qt5? ( dev-lang/qtcore:5 )
> 	!qt5? ( dev-lang/qtcore:4 )
> )
> 
> Fine by me, if you would ask.
> 
> As i said one message earlier: Something like $(qt_use_default qtgui 5)
> 
> which will generate something like this:
> 
> qt4? (
> 	qt5? ( dev-lang/qtcore:5 )
> 	!qt5? ( dev-lang/qtcore:4 )
> )
> !qt5? ( !qt4? ( dev-lang/qtcore:5 ) )
> 
> would help too.
> 
> If you are doing complicated things(and please, do not tell me that
> provided dependency string is simple and understandable by every
> developer in just a second without wanting to "improve" or "simplify"
> it) - do it through eclass. And provide nice API.
> 
> Thanks for listening and sorry if i was too harsh
> 

Oops, sorry dev-qt/qtgui inside the brackets, of course.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Alexandre Rostovtsev]

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

On Tue, 2015-08-11 at 16:04 +0300, Sergey Popov wrote:
> You want to migrate to such decision? Like:
> 
> qt? (
> 	> qt5? ( dev-lang/qtcore:5 )
> 	> !qt5? ( dev-lang/qtcore:4 )
> )
> 
> Fine by me, if you would ask.

That flag should be called "gui". Not "qt".

This would be the real solution to gnome team's gtk/gtk2/gtk3 flag
problem and to qt team's flag problem too.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

[gentoo-dev] Re: useflag policies

[Duncan]

Alexandre Rostovtsev posted on Tue, 11 Aug 2015 09:13:36 -0400 as
excerpted:

> On Tue, 2015-08-11 at 16:04 +0300, Sergey Popov wrote:
>> You want to migrate to such decision? Like:
>> 
>> qt? (
>> 	> qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 )
>> )
>> 
>> Fine by me, if you would ask.
> 
> That flag should be called "gui". Not "qt".
> 
> This would be the real solution to gnome team's gtk/gtk2/gtk3 flag
> problem and to qt team's flag problem too.

Hasn't the X USE flag effectively been the gui USE flag (with curses as a 
semi-gui USE flag)?

With wayland coming along, what will be the effect, since we'll 
effectively have two separate GUIs, then, instead of X being the de facto 
gui USE flag?  Of course X remains the default for now, but for how long?

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

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 11/08/15 23:04, Sergey Popov wrote:
> 11.08.2015 15:32, Michael Palimaka пишет:
>> On 11/08/15 20:17, Sergey Popov wrote:
>>> 09.08.2015 23:28, Ulrich Mueller пишет:
>>>> I disagree with this. Really, REQUIRED_USE should be used sparingly,
>>>> and IMHO the above is not a legitimate usage case for it.
>>>
>>> So, you prefer to make ugly mess of deps here like i posted before or
>>> introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
>>> users even more confused?
>>>
>>> Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
>>> And dependency string like this:
>>>
>>> !berkdb? ( !gdbm? ( sys-libs/gdbm ) )
>>>
>>> One sentence: "WHAT THE HELL?"
>>>
>>> Imagine that it would be dozen of flags. Is it fun to mess with deps
>>> like this for you?
>>
>> Shall we ban this too?
>>
>> ffmpeg? (
>>         libav? ( media-video/libav:= )
>>         !libav? ( media-video/ffmpeg:0= )
>> )
>>
>>
>>
>>
> 
> No, because ffmpeg here is a feature AND name of concrete realization.
> Not ideal case as i would said, but it is acceptable.
> 
> You want to migrate to such decision? Like:
> 
> qt? (
> 	qt5? ( dev-lang/qtcore:5 )
> 	!qt5? ( dev-lang/qtcore:4 )
> )
> 
> Fine by me, if you would ask.

This looks fine to me - I have no particular solution preference. I
understand there's been objection to generic GUI USE flags in the past
though.

> 
> As i said one message earlier: Something like $(qt_use_default qtgui 5)
> 
> which will generate something like this:
> 
> qt4? (
> 	qt5? ( dev-lang/qtcore:5 )
> 	!qt5? ( dev-lang/qtcore:4 )
> )
> !qt5? ( !qt4? ( dev-lang/qtcore:5 ) )
> 
> would help too.
> 
> If you are doing complicated things(and please, do not tell me that
> provided dependency string is simple and understandable by every
> developer in just a second without wanting to "improve" or "simplify"

I disagree but we're getting offtopic. The thread was raised regarding
support of packages that at-most-one-of qt4 or qt5.

Ben is of course right that for these packages, USE="qt4 qt5"
automagically selecting qt5 is not the clearest result and has the
potential for confusion. I feel that usability benefit of this choice
outweighs the negatives. This leaves only a few options:

1. Leave the policy recommendation as-is (letting maintainers adopt or
ignore it as they see fit)

2. Veto the policy recommendation and force something different
(maintainers who disagree will likely either drop support for multiple
qt versions or stop maintaining the package completely)

3. Create a whole new solution like USE="gui" (what happens if I have
multiple gui implementation USE flags set?)

Re: [gentoo-dev] Re: useflag policies

[Alexandre Rostovtsev]

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

On Wed, 2015-08-12 at 00:02 +1000, Michael Palimaka wrote:
> 3. Create a whole new solution like USE="gui" (what happens if I have
> multiple gui implementation USE flags set?)

This is what I would suggest. It would remove 90% of the problem since
most applications use only one gui toolkit.

If no toolkit USE flags are set, go with the "best" (most stable, best
supported) toolkit.

If multiple flags are set - here you have a choice. The user-friendly
approach is to add some logic to find the "best" toolkit out of the
ones for which a flag is set (this gets complicated in the theoretical
case of three toolkits).

However, the user-friendly approach is completely unworkable when there
are reverse dependencies on your package (plugins for example) that
require a specific toolkit.

So a better choice might be REQUIRED_USE, *but* then you must adjust
package.use in all profiles to allow your package to be emerged without
forcing a user to manually set/unset flags.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 11/08/15 09:04 AM, Sergey Popov wrote:
> 11.08.2015 15:32, Michael Palimaka пишет:
>> On 11/08/15 20:17, Sergey Popov wrote:
>>> 09.08.2015 23:28, Ulrich Mueller пишет:
>>>> I disagree with this. Really, REQUIRED_USE should be used
>>>> sparingly, and IMHO the above is not a legitimate usage case
>>>> for it.
>>> 
>>> So, you prefer to make ugly mess of deps here like i posted
>>> before or introduce some really unneded USE-flag like 'gui',
>>> 'qt', etc. to make users even more confused?
>>> 
>>> Really, look at man-db ebuild. Especially on berkdb and gdbm
>>> USE flags. And dependency string like this:
>>> 
>>> !berkdb? ( !gdbm? ( sys-libs/gdbm ) )
>>> 
>>> One sentence: "WHAT THE HELL?"
>>> 
>>> Imagine that it would be dozen of flags. Is it fun to mess with
>>> deps like this for you?
>> 
>> Shall we ban this too?
>> 
>> ffmpeg? ( libav? ( media-video/libav:= ) !libav? (
>> media-video/ffmpeg:0= ) )
>> 
>> 
>> 
>> 
> 
> No, because ffmpeg here is a feature AND name of concrete
> realization. Not ideal case as i would said, but it is acceptable.
> 
> You want to migrate to such decision? Like:
> 
> qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) )
> 
> Fine by me, if you would ask.
> 
> As i said one message earlier: Something like $(qt_use_default
> qtgui 5)
> 
> which will generate something like this:
> 
> qt4? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) 
> !qt5? ( !qt4? ( dev-lang/qtcore:5 ) )
> 
> would help too.

Woah -- why would qt5 be a dep when both flags are off?  If you have a
package that -needs- one version enabled, then in that case I do fully
support REQUIRED_USE="|| ( qt4 qt5 )".  '||' being the one-or-more-of
operator.

The other alternative here would be that there is no qt5 flag, just a
qt4 one, and the qt4 one toggles qt5 off and qt4 on.  And that just
isn't pretty, so let's not do that.

And using this form of REQUIRED_USE I believe (if I understand what
QA's and QT's stances are on this) is not in conflict with either
group, right?



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

iF4EAREIAAYFAlXKDosACgkQAJxUfCtlWe2Z8QD/Z+NvyJ0VXoIQH/KRPy8Asete
iXZTpA1QgLDh4xYJE9YBAOTV61mJP472jBu/kEmJOK9cZPFW9PfJ15I0IvoBWdNF
=1oaz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

11.08.2015 18:02, Ian Stakenvicius пишет:
> On 11/08/15 09:04 AM, Sergey Popov wrote:
>> 11.08.2015 15:32, Michael Palimaka пишет:
>>> On 11/08/15 20:17, Sergey Popov wrote:
>>>> 09.08.2015 23:28, Ulrich Mueller пишет:
>>>>> I disagree with this. Really, REQUIRED_USE should be used
>>>>> sparingly, and IMHO the above is not a legitimate usage case
>>>>> for it.
>>>>
>>>> So, you prefer to make ugly mess of deps here like i posted
>>>> before or introduce some really unneded USE-flag like 'gui',
>>>> 'qt', etc. to make users even more confused?
>>>>
>>>> Really, look at man-db ebuild. Especially on berkdb and gdbm
>>>> USE flags. And dependency string like this:
>>>>
>>>> !berkdb? ( !gdbm? ( sys-libs/gdbm ) )
>>>>
>>>> One sentence: "WHAT THE HELL?"
>>>>
>>>> Imagine that it would be dozen of flags. Is it fun to mess with
>>>> deps like this for you?
>>>
>>> Shall we ban this too?
>>>
>>> ffmpeg? ( libav? ( media-video/libav:= ) !libav? (
>>> media-video/ffmpeg:0= ) )
>>>
>>>
>>>
>>>
> 
>> No, because ffmpeg here is a feature AND name of concrete
>> realization. Not ideal case as i would said, but it is acceptable.
> 
>> You want to migrate to such decision? Like:
> 
>> qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) )
> 
>> Fine by me, if you would ask.
> 
>> As i said one message earlier: Something like $(qt_use_default
>> qtgui 5)
> 
>> which will generate something like this:
> 
>> qt4? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) 
>> !qt5? ( !qt4? ( dev-lang/qtcore:5 ) )
> 
>> would help too.
> 
> Woah -- why would qt5 be a dep when both flags are off?  If you have a
> package that -needs- one version enabled, then in that case I do fully
> support REQUIRED_USE="|| ( qt4 qt5 )".  '||' being the one-or-more-of
> operator.
> 
> The other alternative here would be that there is no qt5 flag, just a
> qt4 one, and the qt4 one toggles qt5 off and qt4 on.  And that just
> isn't pretty, so let's not do that.
> 
> And using this form of REQUIRED_USE I believe (if I understand what
> QA's and QT's stances are on this) is not in conflict with either
> group, right?
> 
> 
> 
> 

Again - i am talking about package that CAN not be build without ANY of
Qt GUIs.

If it can be build without GUIs at all - THAT'S A DIFFERENT STORY and
solution for it is diffirent

Sorry for the caps, but i am a bit tired of repeating myself.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Peter Stuge]

Sergey Popov wrote:
> qt? (
> 	qt5? ( dev-lang/qtcore:5 )
> 	!qt5? ( dev-lang/qtcore:4 )
> )
> 
> Fine by me, if you would ask.

May I suggest instead:

qt? (
	qt5? ( dev-lang/qt$something:5 )
	qt4? ( dev-lang/qt$something:4 )
)


Alexandre Rostovtsev wrote:
> > qt? (
> > 	> qt5? ( dev-lang/qtcore:5 )
> > 	> !qt5? ( dev-lang/qtcore:4 )
> > )
> > 
> > Fine by me, if you would ask.
> 
> That flag should be called "gui". Not "qt".
> 
> This would be the real solution to gnome team's gtk/gtk2/gtk3 flag
> problem and to qt team's flag problem too.

Unlike gtk+, using Qt does not mean that there is any GUI.

Qt provides many things, and sometimes non-GUI Qt bits are used
independently in console-only applications.


//Peter

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

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

12.08.2015 22:14, Peter Stuge пишет:
> May I suggest instead:
> 
> qt? (
> 	qt5? ( dev-lang/qt$something:5 )
> 	qt4? ( dev-lang/qt$something:4 )
> )

And what would be if USE="qt -qt4 -qt5"? Should we introduce a
REQUIRED_USE for that? Well, congrats then, USE qt becomes useless,
cause it does not improve the situation in case of 'at-most-one-of'
implementation.

e.g.

REQUIRED_USE="qt? ( ^^ ( qt4 qt5 ) )" simple shrinked to current
REQUIRED_USE="^^ ( qt4 qt5 )"

Again, it's about packages that can not be build with both
implementations at the same time

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/08/15 21:38, Sergey Popov wrote:
> <qa team lead hat>
> 
> In short - apropriate REQUIRED_USE with setting recommended 
> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
> 
> </qa team lead hat>
Strong -1.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVyFJ0AAoJENQqWdRUGk8BdYkP/3ZNmUAawdlBnX7Bjlc8io0c
AGVTFCFX8tjbu4nnx1jZe9ZXB3SEBfHs8rb8/I/9h6BmDUi9jU2ca7E9Iw27/IDg
qxd7xy+iGY00IjLgtWooI06ELJRv7KHxAAOb9UOpJuRZvxW4a1MaUgE2lddy+c9r
7wNJaHjgdkm9qJOejaf/kWiYpwOM6HYWZlV9Mq7EV3Jzn1K9u8gRJDB9Rf0uIwoe
Tt/bD1wbQvMKzgDXdxh8zlNaI6F2v+xUFF8UJqjtEptjVHN/BFGTL8Rxbdm39eIk
PqiyfMQsjGSk6OLJe60dD5nnRHxwVz+r97O9Kwag7bGdaTeRB9/8zITHHe5GgvbW
v3ibxSfS1/2rOmynMJmj1/tFeFyulDcAhajUdB6dpX/Pv2wyUN8SluezrT0VIb1G
IGMkzRAzqwYAbdhe/y6YcO6lFtKDcET4NpuLo6cHhDzYmkcHWjcROHOOghtpLL9w
TvYwyQmCA4BN9y/NBw6Sw80TeumRKGr0Uh1SyvNwb/JaMRWEvR0NdfljOtPk4cjS
mf55dWs85wrZTSvqpNS1riAI+UIXeB5A/Rwb4F/mvvV4B0tabnoPMxyNGqk7ZP+n
AC4pCMoI29saUedBjl+Em8iG1dYL2KCAUE4ItONl74AchzQBToN1zcpHegEBGKjt
cCJj84GIjFWf3BVm63xa
=MKyo
-----END PGP SIGNATURE-----

[gentoo-dev] Re: useflag policies

[Sergey Popov]

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

I'd suggest to make a QA team meeting to override this policies with
more correct and rationale.

Qt team members are greatly appreciated on this meeting. Even more, i
think that we should not take any decision on this without at least Qt
team lead(or half of Qt team devs)

So, let's arrange some time and talk about this, cause it is really
confusing. Qt team point is understandable, but it's still wrong. Let's
make some consensus here.

02.08.2015 19:34, Ben de Groot пишет:
> Recently some team members of the Qt project have adopted these ebuild
> policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies
> 
> I have an issue with the policy adopted under "Requires one of two Qt
> versions". In my opinion, in the case where a package offers a choice
> between qt4 or qt5, we should express this in explicit useflags and a
> REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice.
> 
> Other developers state that users are not interested in such
> implementation details, or that forced choice through REQUIRED_USE is
> too much of a hassle. This results in current ebuilds such as quassel to
> not make it clear that qt4 is an option.
> 
> This goes against the principle of least surprise, as well as against QA
> recommendations. I would like to hear specifically from QA about how we
> should proceed, but comments from the wider developer community are also
> welcome.
> 
> -- 
> Cheers,
> 
> Ben | yngwin
> Gentoo developer
> 


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: useflag policies

[Daniel Campbell (zlg)]

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

On 08/11/2015 03:41 AM, Sergey Popov wrote:
> I'd suggest to make a QA team meeting to override this policies
> with more correct and rationale.
> 
> Qt team members are greatly appreciated on this meeting. Even more,
> i think that we should not take any decision on this without at
> least Qt team lead(or half of Qt team devs)
> 
> So, let's arrange some time and talk about this, cause it is
> really confusing. Qt team point is understandable, but it's still
> wrong. Let's make some consensus here.
> 
> 02.08.2015 19:34, Ben de Groot пишет:
>> Recently some team members of the Qt project have adopted these
>> ebuild policies:
>> https://wiki.gentoo.org/wiki/Project:Qt/Policies
>> 
>> I have an issue with the policy adopted under "Requires one of
>> two Qt versions". In my opinion, in the case where a package
>> offers a choice between qt4 or qt5, we should express this in
>> explicit useflags and a REQUIRED_USE="^^ ( qt4 qt5 )". This
>> offers the user the clearest choice.
>> 
>> Other developers state that users are not interested in such 
>> implementation details, or that forced choice through
>> REQUIRED_USE is too much of a hassle. This results in current
>> ebuilds such as quassel to not make it clear that qt4 is an
>> option.
>> 
>> This goes against the principle of least surprise, as well as
>> against QA recommendations. I would like to hear specifically
>> from QA about how we should proceed, but comments from the wider
>> developer community are also welcome.
>> 
>> -- Cheers,
>> 
>> Ben | yngwin Gentoo developer
>> 
> 
> 
I'm interested in this meeting as well, as maintainer of a package
that can be built with one of two toolkit versions. At the moment, I'm
using REQUIRED_USE with a preference preset for users that don't care,
but it does cause a problem when both flags are set (so it's something
I'd like to fix). I'd like to be part of the conversation if you don't
mind.

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

iQIcBAEBCAAGBQJVykQPAAoJEAEkDpRQOeFwVAgP+wYqVva9YHWmUOwC2dyrUFhx
EjnPHBRaAsd6vOdoKKoFbO2c4wMhcoXb2C9pgLDw4O+eB2Q7JE3iMiiG/vAwGGtN
10meoAjvFV+DxpB7EYiHNj8NtlKq8PAncHusu6H/eP7YwdS37ruO4E89nBbXzxjU
JQru2bxL6Jf7m/LuI5lihdU6fwe1GrsDz0fCaeZ/49zBE8EPY1PjDbV8G8vHq/S6
UAgGXmFbzN8lPXfgBgnaD4O6So+WrhILUeTy4CVUQu0599W4UFmLqOmupeRHD0SM
wHjtJ/0gW+Wfb7VbuQsfrmNYuu0Fh/Wx15qs62/8YcgIOxb5YI31cefPa7e3HZbm
RQ52JC16Pl7VxPEsf5jhcQ6+QCpdOi/jH7B72JQiSgmtLF9N6j4kcr8XGtJB/HLy
PlJES1865ugS8LWpMiJCCwGyO8o/lOi4scbumw+XxjWj43Z93d66wGK84Yf2goAL
VBVA0JjzrJ46EIrBbqOPECMZZvJjeq4t28V3DHAdLPZmxhvLQjIjEqb8wywR5USa
NJ4kDgP5H85udznBk7JWapFu+ipphFm8uzKt6nqCeAfVc/y3n4rLZ9aUDCBVKodv
lzr652TmUw2sBvmhM6oRqsGZuMg6t0peBOOTFjTMJl+WYG+eUybvsWk9RQ9HQpuW
aqpPa6GiLL9Gbx8JTX8F
=JOKI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: useflag policies

[Gregory Woodbury]

Is a possible solution something like an eselect module to indicate
the preferred
interface kit? It could default to any package that is available with
a sequential
set of preferred order.
Then ebuild would consult the eselect module, and users who care can
select the kit they want, and users who don't care/know get the default.


Just a nickel's worth opinion. Due to inflation it isn't 2 cents any more.
-- 
G.Wolfe Woodbury
redwolfe@gmail.com

Re: [gentoo-dev] Re: useflag policies

[Rich Freeman]

On Tue, Aug 11, 2015 at 3:13 PM, Gregory Woodbury <redwolfe@gmail.com> wrote:
> Is a possible solution something like an eselect module to indicate
> the preferred
> interface kit? It could default to any package that is available with
> a sequential
> set of preferred order.
> Then ebuild would consult the eselect module, and users who care can
> select the kit they want, and users who don't care/know get the default.

That still neglects the case where a user just wanted to say "use the
best version of qt for any particular package," which I'd argue is
probably the most common use case.  It may not make sense to have one
global preference system-wide, and managing it per-package is painful.
It really does make sense to leave it up to the maintainer, while
still letting people either turn off qt entirely if they'd prefer to
do so, or override the default implementation when they really want
to.

There is always requiring any package that supports qt to enable
either qt4 or qt5 by default, so the typical user who wants qt does
nothing, the typical user who doesn't want qt sets USE="-qt4 -qt5",
and then anybody who wants to override things per-package can do so.
That is simple to define in ebuilds, and you can set REQUIRED_USE to
prevent them both from being set.  It just means having qt support by
default all over the tree and forcing people who don't want it to
explicitly turn it off.  That is simple to do at least, but not really
in keeping with the general spirit of the base profile being a minimal
one.  And it would still be difficult to do anything at the profile
level if it were appropriate to do so.

-- 
Rich

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

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

On 11/08/15 03:13 PM, Gregory Woodbury wrote:
> Is a possible solution something like an eselect module to
> indicate the preferred interface kit? It could default to any
> package that is available with a sequential set of preferred
> order. Then ebuild would consult the eselect module, and users
> who care can select the kit they want, and users who don't
> care/know get the default.
> 
> 
> Just a nickel's worth opinion. Due to inflation it isn't 2 cents
> any more.
> 

Firstly, that's what USE flags are supposed to be for in the first
place.

Secondly, although something could be done within phase functions to
deal with whatever the eselected iface-kit is, that afaik isn't
something that would be permitted in global scope and so RDEPEND
wouldn't be changed.  Also I forsee major issues with binary
packages, as right now the use flag settings partly determine
whether a binpkg can be applied on another system based on that
system's profile/use-flag settings (and those would now be gone).

If you're talking instead about using an eselect module to adjust or
auto-fill /etc/portage/package.use ..... i dunno.  I think the
metadata setup to get that right is is still going to be a lot of
work for dev's to do (meaning it won't be done).


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

iF4EAREIAAYFAlXKUhwACgkQAJxUfCtlWe1WhQEAlpdOL975yR+jYyNQNZWKML6l
ZJlKzxrEKM1JMfLs+acA/0ypsvc/DLULgZWqZY7t+KdbappPNlI/K6YJDPyeKtS7
=/9HJ
-----END PGP SIGNATURE-----