useflag policies

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

Re: useflag policies

Alexis Ballier-2
On Wed, 12 Aug 2015 14:24:06 -0400
Ian Stakenvicius <[hidden email]> 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
> > <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Alexis Ballier-2
In reply to this post by Ciaran McCreesh-4
On Wed, 12 Aug 2015 19:25:37 +0100
Ciaran McCreesh <[hidden email]> wrote:

> On Wed, 12 Aug 2015 20:19:08 +0200
> Alexis Ballier <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Ciaran McCreesh-4
On Wed, 12 Aug 2015 21:22:48 +0200
Alexis Ballier <[hidden email]> wrote:

> On Wed, 12 Aug 2015 19:25:37 +0100
> Ciaran McCreesh <[hidden email]> wrote:
> > On Wed, 12 Aug 2015 20:19:08 +0200
> > Alexis Ballier <[hidden email]> 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

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

Re: useflag policies

Kent Fredric
In reply to this post by Ciaran McCreesh-4
On 12 August 2015 at 16:21, Ciaran McCreesh
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Patrick Lauer
In reply to this post by William Hubbs
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


Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Zac Medico-2
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

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


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 Ian Stakenvicius-2
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


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 Ian Stakenvicius-2
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


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 Peter Stuge-4
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


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


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

Reply | Threaded
Open this post in threaded view
|

Re: useflag policies

Ciaran McCreesh-4
In reply to this post by Patrick Lauer
On Thu, 13 Aug 2015 08:44:58 +0800
Patrick Lauer <[hidden email]> 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

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

Re: useflag policies

Kent Fredric
On 14 August 2015 at 05:37, Ciaran McCreesh
<[hidden email]> 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

1 ... 4567