Mailing List Archive

useflag policies
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
Re: useflag policies [ In reply to ]
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
Re: useflag policies [ In reply to ]
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ł
Re: useflag policies [ In reply to ]
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
Re: useflag policies [ In reply to ]
>>>>> 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
Re: useflag policies [ In reply to ]
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
Re: useflag policies [ In reply to ]
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
Re: useflag policies [ In reply to ]
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
Re: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
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
Re: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
^^ 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
Re: useflag policies [ In reply to ]
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
Re: useflag policies [ In reply to ]
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.
Re: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
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: useflag policies [ In reply to ]
-----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: useflag policies [ In reply to ]
-----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: useflag policies [ In reply to ]
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: Re: useflag policies [ In reply to ]
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

1 2 3 4 5 6  View All