useflag policies

classic Classic list List threaded Threaded
135 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Rich Freeman
On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov <[hidden email]> wrote:

> 11.08.2015 16:11, James Le Cuirot пишет:
>> On Tue, 11 Aug 2015 15:58:49 +0300
>> Sergey Popov <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Sergey Popov
In reply to this post by Michael Palimaka
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


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Sergey Popov
In reply to this post by Rich Freeman
11.08.2015 16:36, Rich Freeman пишет:

> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov <[hidden email]> wrote:
>> 11.08.2015 16:11, James Le Cuirot пишет:
>>> On Tue, 11 Aug 2015 15:58:49 +0300
>>> Sergey Popov <[hidden email]> 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


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Michael Palimaka
In reply to this post by Sergey Popov
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.


Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Michael Palimaka
In reply to this post by Sergey Popov
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?)


Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Alexandre Rostovtsev-2
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.

signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Rich Freeman
In reply to this post by Sergey Popov
On Tue, Aug 11, 2015 at 9:42 AM, Sergey Popov <[hidden email]> wrote:

> 11.08.2015 16:36, Rich Freeman пишет:
>> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov <[hidden email]> wrote:
>>> 11.08.2015 16:11, James Le Cuirot пишет:
>>>> On Tue, 11 Aug 2015 15:58:49 +0300
>>>> Sergey Popov <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Rich Freeman
In reply to this post by Sergey Popov
On Tue, Aug 11, 2015 at 9:39 AM, Sergey Popov <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Ian Stakenvicius-2
In reply to this post by Sergey Popov
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Michael Palimaka
In reply to this post by Rich Freeman
On 12/08/15 00:29, Rich Freeman wrote:

> On Tue, Aug 11, 2015 at 9:39 AM, Sergey Popov <[hidden email]> 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?


Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Ian Stakenvicius-2
In reply to this post by Sergey Popov
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Ian Stakenvicius-2
In reply to this post by Sergey Popov
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Ian Stakenvicius-2
In reply to this post by Rich Freeman
-----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 <[hidden email]>
> wrote:
>> 11.08.2015 16:36, Rich Freeman пишет:
>>> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov
>>> <[hidden email]> wrote:
>>>> 11.08.2015 16:11, James Le Cuirot пишет:
>>>>> On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov
>>>>> <[hidden email]> 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-----

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Rich Freeman
In reply to this post by Michael Palimaka
On Tue, Aug 11, 2015 at 10:42 AM, Michael Palimaka
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Daniel Campbell (zlg)
In reply to this post by Sergey Popov
-----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-----

Reply | Threaded
Open this post in threaded view
|

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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Rich Freeman
On Tue, Aug 11, 2015 at 3:13 PM, Gregory Woodbury <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Ian Stakenvicius-2
In reply to this post by Gregory Woodbury
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Ciaran McCreesh-4
In reply to this post by Michael Palimaka
On Tue, 11 Aug 2015 23:30:31 +1000
Michael Palimaka <[hidden email]> 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

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Duncan-42
In reply to this post by Alexandre Rostovtsev-2
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


1234567