On 14 August 2015 at 05:37, Ciaran McCreesh
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 s
On Thu, 13 Aug 2015 08:44:58 +0800
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_prete
-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
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
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,
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
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
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 o
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 act
On 12 August 2015 at 16:21, Ciaran McCreesh
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 happen
On Wed, 12 Aug 2015 21:22:48 +0200
Alexis Ballier wrote:
> On Wed, 12 Aug 2015 19:25:37 +0100
> Ciaran McCreesh wrote:
> > On Wed, 12 Aug 2015 20:19:08 +0200
> > Alexis Ballier wrote:
> > > pkg_pretend still needs to be executed to guess what useflags are
> > > enabled or not, which information
On Wed, 12 Aug 2015 19:25:37 +0100
Ciaran McCreesh wrote:
> On Wed, 12 Aug 2015 20:19:08 +0200
> Alexis Ballier 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 im
-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
> 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 +020
On Wed, 12 Aug 2015 14:24:06 -0400
Ian Stakenvicius 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
> > wrote:
> >
> >>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> >>
>
Sergey Popov wrote:
> qt? (
> qt5? ( dev-lang/qtcore:5 )
> !qt5? ( dev-lang/qtcore:4 )
> )
>
> Fine by me, if you would ask.
May I suggest instead:
qt? (
qt5? ( dev-lang/qt$something:5 )
qt4? ( dev-lang/qt$something:4 )
)
Alexandre Rostovtsev wrote:
> > qt? (
> >
On Wed, 12 Aug 2015 14:36:12 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12/08/15 01:52 PM, Alexis Ballier wrote:
> > On Wed, 12 Aug 2015 13:39:21 -0400 Ian Stakenvicius
> > wrote:
> >>
> >> ...OR we could just adjust PMS to assume flag order determ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:52 PM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 13:39:21 -0400 Ian Stakenvicius
> wrote:
>>
>> ...OR we could just adjust PMS to assume flag order determines
>> precedence and still not bother with a new operator: For "^^ (
>> a
On Wed, 12 Aug 2015 20:19:08 +0200
Alexis Ballier 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, d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 02:00 PM, Ulrich Mueller wrote:
>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
>
>>> pkg_pretend() { if use qt4; then required_use -qt5 else
>>> required_use qt5 fi }
>
>> And how would the PM understand that -qt5 is conditional up
On Wed, 12 Aug 2015 20:00:42 +0200
Ulrich Mueller wrote:
> > On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> >> pkg_pretend() {
> >> if use qt4; then
> >> required_use -qt5
> >> else
> >> required_use qt5
> >> fi
> >> }
>
> > And how would the PM understand that -qt5
-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
> wrote:
>
>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
>>
pkg_pretend() { if use qt4; then required_use -qt5 else
required_use qt5 f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 02:18 PM, Ian Stakenvicius wrote:
> On 12/08/15 02:00 PM, Ulrich Mueller wrote:
>>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
>
pkg_pretend() { if use qt4; then required_use -qt5 else
required_use qt5 fi }
>
>>> And how
On Wed, 12 Aug 2015 20:00:42 +0200
Ulrich Mueller wrote:
> > On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
>
> >> pkg_pretend() {
> >> if use qt4; then
> >> required_use -qt5
> >> else
> >> required_use qt5
> >> fi
> >> }
>
> > And how would the PM understand that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:50 PM, Ciaran McCreesh wrote:
> On Wed, 12 Aug 2015 19:43:55 +0200 Ulrich Mueller
> wrote:
>>> On Wed, 12 Aug 2015, Ulrich Mueller wrote:
>>> Hm, how about adding a new PM command like "required_use foo
>>> -bar"? It would be used
> 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 au
On Wed, 12 Aug 2015 13:39:21 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12/08/15 01:22 PM, Alexis Ballier wrote:
> > On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius
> > wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>
> >>
On Wed, 12 Aug 2015 19:43:55 +0200
Ulrich Mueller wrote:
> > On Wed, 12 Aug 2015, Ulrich Mueller wrote:
> > Hm, how about adding a new PM command like "required_use foo -bar"?
> > It would be used exclusively in pkg_pretend, and tell the PM to
> > suggest the necessary package.use changes to t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:38 PM, Ulrich Mueller wrote:
>> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
>
>> The opposing viewpoint was ferringb believing he could do
>> "automatic dependency resolution" for a build server setup,
>> without trying it and wit
> On Wed, 12 Aug 2015, Ulrich Mueller wrote:
> Hm, how about adding a new PM command like "required_use foo -bar"?
> It would be used exclusively in pkg_pretend, and tell the PM to
> suggest the necessary package.use changes to the user (or even update
> them automatically with the appropriate
On Wed, 12 Aug 2015 19:38:21 +0200
Ulrich Mueller wrote:
> > On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> > The opposing viewpoint was ferringb believing he could do "automatic
> > dependency resolution" for a build server setup, without trying it
> > and without an implementation, and that a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:22 PM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
>>> On 12/08/15 01:00 PM, Alexis Ba
> On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
> The opposing viewpoint was ferringb believing he could do "automatic
> dependency resolution" for a build server setup, without trying it
> and without an implementation, and that a human-readable pkg_pretend
> would somehow preclude that.
Hm, h
On Wed, 12 Aug 2015 09:38:19 -0500
William Hubbs wrote:
> I always wondered why pkg_pretend never caught on.
>
> I to can see the advantage of it over REQUIRED_USE; it would allow the
> package maintainer to give specific error messages about why use flag
> combinations are invalid for a package.
On Wed, 12 Aug 2015 13:06:43 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
> > On 12/08/15 01:00 PM, Alexis Ballier wrote:
> >> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
> >> wrote:
> >
> >>> -
On Wed, 12 Aug 2015 17:08:59 +0200
Ulrich Mueller wrote:
> > On Wed, 12 Aug 2015, Alexis Ballier wrote:
> > i.e. something that really tells the PM how to automate the choice:
> > - 'qt5 -> !qt4' is rather straightforward to solve and tells the PM
> > how (note that it is not equivalent to 'qt
> On Wed, 12 Aug 2015, Alexis Ballier wrote:
> it is more in the line of what we currently do, but that doesn't
> resolve the 'sat' problem: it doesnt make clear we don't want to
> satisfy it but rather walk through a list of causes and consequences
> now that i'm thinking more about it, kill
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
> On 12/08/15 01:00 PM, Alexis Ballier wrote:
>> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
>> wrote:
>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>> On 12/08/15 12:42 PM, Ulric
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:00 PM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
>>> On Wed, 12 Aug 2015, Ian Stakenvi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 12:53 PM, Ulrich Mueller wrote:
>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
>
>> On 12/08/15 11:55 AM, Alexis Ballier wrote:
>>> I think it is better seen as a list of implications, esp.
>>> for this kind of questions :) With tha
On Wed, 12 Aug 2015 12:57:25 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
> > On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
> >> 2 - is there a particular reasoning for the - in front of qt4
> >> here? I only ask
On Wed, 12 Aug 2015 12:27:15 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12/08/15 11:55 AM, Alexis Ballier wrote:
> > On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius
> > wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 12:42 PM, Ulrich Mueller wrote:
> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
>> 2 - is there a particular reasoning for the - in front of qt4
>> here? I only ask because it would seem that a single
>> default-enable should suffice in li
> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
> On 12/08/15 11:55 AM, Alexis Ballier wrote:
>> I think it is better seen as a list of implications, esp. for
>> this kind of questions :) With that in mind, there is no
>> autounmask-write: effective USE for a given package is input USE
>> with
> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
> On 12/08/15 11:08 AM, Ulrich Mueller wrote:
>> I was thinking about some syntax like this:
>>
>> REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )"
>>
>> The package manager would first evaluate each group in
>> REQUIRED_USE with the original set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 11:55 AM, Alexis Ballier wrote:
> On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 12/08/15 11:08 AM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Alexis
On Wed, 12 Aug 2015 11:30:39 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12/08/15 11:08 AM, Ulrich Mueller wrote:
> >> On Wed, 12 Aug 2015, Alexis Ballier wrote:
> >
> >> i.e. something that really tells the PM how to automate the
> >> choice: -
On Wed, 12 Aug 2015 17:08:59 +0200
Ulrich Mueller wrote:
> > On Wed, 12 Aug 2015, Alexis Ballier wrote:
>
> > i.e. something that really tells the PM how to automate the choice:
> > - 'qt5 -> !qt4' is rather straightforward to solve and tells the PM
> > how (note that it is not equivalent to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 11:08 AM, Ulrich Mueller wrote:
>> On Wed, 12 Aug 2015, Alexis Ballier wrote:
>
>> i.e. something that really tells the PM how to automate the
>> choice: - 'qt5 -> !qt4' is rather straightforward to solve and
>> tells the PM how (not
> On Wed, 12 Aug 2015, Alexis Ballier wrote:
> i.e. something that really tells the PM how to automate the choice:
> - 'qt5 -> !qt4' is rather straightforward to solve and tells the PM how
> (note that it is not equivalent to 'qt4 -> !qt5')
> - '^^ ( qt5 qt4 )' requires the PM to make a choi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 09:40 AM, Michael Orlitzky wrote:
> At the very least, we need to be able to tag REQUIRED_USE
> conflicts with human readable error messages. OK, so I know I
> can't have USE="qt4 qt5" for this package... but why? How do I
> fix it? We ca
On Wed, Aug 12, 2015 at 09:40:00AM -0400, Michael Orlitzky wrote:
> On 08/12/2015 12:21 AM, Ciaran McCreesh wrote:
> > On Tue, 11 Aug 2015 23:30:31 +1000
> > Michael Palimaka wrote:
> >> I invite you to reproduce the problem yourself then make the
> >> judgement. Using REQUIRED_USE like this makes
On 08/12/2015 12:21 AM, Ciaran McCreesh wrote:
> On Tue, 11 Aug 2015 23:30:31 +1000
> Michael Palimaka 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
On Wed, 12 Aug 2015 05:21:20 +0100
Ciaran McCreesh wrote:
> On Tue, 11 Aug 2015 23:30:31 +1000
> Michael Palimaka 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 (excep
On Tue, 11 Aug 2015 23:30:31 +1000
Michael Palimaka 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 g
-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 eb
On Tue, Aug 11, 2015 at 3: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 mo
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 d
-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 tak
On Tue, Aug 11, 2015 at 10:42 AM, Michael Palimaka
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 use
-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
> wrote:
>> 11.08.2015 16:36, Rich Freeman пишет:
>>> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov
>>> wrote:
11.08.2015 16:11, James Le Cuirot пишет:
>
-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,
-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
-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
On Tue, Aug 11, 2015 at 9:39 AM, 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
On Tue, Aug 11, 2015 at 9:42 AM, Sergey Popov wrote:
> 11.08.2015 16:36, Rich Freeman пишет:
>> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov wrote:
>>> 11.08.2015 16:11, James Le Cuirot пишет:
On Tue, 11 Aug 2015 15:58:49 +0300
Sergey Popov wrote:
> If both of flags are not s
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
11.08.2015 16:36, Rich Freeman пишет:
> On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov wrote:
>> 11.08.2015 16:11, James Le Cuirot пишет:
>>> On Tue, 11 Aug 2015 15:58:49 +0300
>>> Sergey Popov wrote:
>>>
If both of flags are not set - we stick to default.
Should this be set in EVERY ebu
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 fr
On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov wrote:
> 11.08.2015 16:11, James Le Cuirot пишет:
>> On Tue, 11 Aug 2015 15:58:49 +0300
>> Sergey Popov wrote:
>>
>>> If both of flags are not set - we stick to default.
>>> Should this be set in EVERY ebuild explicitly?
>>>
>>> Maybe provide some sug
11.08.2015 16:11, James Le Cuirot пишет:
> On Tue, 11 Aug 2015 15:58:49 +0300
> Sergey Popov 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
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 solu
On Tue, 11 Aug 2015 15:58:49 +0300
Sergey Popov 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
11.08.2015 16:04, Sergey Popov пишет:
> 11.08.2015 15:32, Michael Palimaka пишет:
>> On 11/08/15 20:17, Sergey Popov wrote:
>>> 09.08.2015 23:28, Ulrich Mueller пишет:
I disagree with this. Really, REQUIRED_USE should be used sparingly,
and IMHO the above is not a legitimate usage case fo
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
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
11.08.2015 13:18, Georg Rudoy пишет:
>
> You missed the fourth option: the package can not be built without Qt
> GUI, but it supports building with either Qt version at the same time.
>
Not a problem.
REQUIRED_USE="|| ( qt4 qt5 )"
At least one of flags should be enabled, but both can be enable
2015-08-11 11:10 GMT+01:00 Sergey Popov :
>
> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
> package even exists?)
>
Take app-text/poppler as an "officially supported" example.
Take x11-libs/qwt as an example of a library that gets a patched library
name to avoid colli
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',
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, bu
What's not clear with 'apropriate' word in my sentence?
Let me clarify - if package depend either on Qt4 or Qt5 and CAN not be
built with Qt at all - force this behaviour with REQUIRED_USE.
I think that it was obvious that i have meant exactly this case, cause
other cases are unreasonable here.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/08/15 21:38, Sergey Popov wrote:
>
>
> In short - apropriate REQUIRED_USE with setting recommended
> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
>
>
Strong -1.
- --
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
--
On Sun, Aug 9, 2015 at 12:38 PM, Sergey Popov wrote:
>
>
> In short - apropriate REQUIRED_USE with setting recommended
> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
>
>
>
> That's most painless decision for both developers and users. Developers
> do not need to maintain ugly dependencies lik
On Sun, 2015-08-09 at 22:38 +0300, Sergey Popov wrote:
>
>
> In short - apropriate REQUIRED_USE with setting recommended
> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
>
>
If a package has optional guis, why should users of the default profile get any
gui enabled by default? The default pro
On 03/08/2015 15:07, Dale wrote:
> Michael Palimaka wrote:
>> On 03/08/15 07:14, NP-Hardass wrote:
>>> ^^ has the pleasant side effect of being easier to read, as a user. The
>>> user receives a message saying "at-most-one-of" instead of some
>>> convoluted other expression that they don't understa
Michael Palimaka wrote:
> On 03/08/15 07:14, NP-Hardass wrote:
>> ^^ has the pleasant side effect of being easier to read, as a user. The
>> user receives a message saying "at-most-one-of" instead of some
>> convoluted other expression that they don't understand.
>>
>> I am all for the use of ^^ ad
On Mon, 3 Aug 2015 21:23:37 +1000
Michael Palimaka wrote:
> On 03/08/15 07:14, NP-Hardass wrote:
> > ^^ has the pleasant side effect of being easier to read, as a user.
> > The user receives a message saying "at-most-one-of" instead of some
> > convoluted other expression that they don't understa
86 matches
Mail list logo
