FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-17-2012, 11:49 AM
Ben de Groot
 
Default GLEP: gentoo sync based unified deps proposal

On 17 September 2012 18:55, Alex Alexander <alex.alexander@gmail.com> wrote:
> On Sep 17, 2012 6:13 AM, "Brian Harring" <ferringb@gmail.com> wrote:
>>
>> On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
>> > On Sep 16, 2012 4:55 PM, "Brian Harring" <[1]ferringb@gmail.com>
>> > wrote:
>> > >
>> > > Folks-
>> > >
>> > > Keeping it short and quick, a basic glep has been written for what
>> > I'm
>> > > proposing for DEPENDENCIES enhancement.
>> > >
>> > > The live version of the doc is available at
>> > >
>> >
>> > [2]http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
>> > ndencies.html
>> >
>> > Am I the only one who thinks that this dep:{build,...} thing looks
>> > really ugly and is hard to read?
>> >
>> > IMO simply removing the "dep" part would greatly improve things:
>>
>> That 'dep' part isn't great, but it's added for a reason; to unify
>> with USE_EXPAND/use group intended syntax. There's a reference in
>> there to
>> http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which
>> I'll formalize soon enough.
>>
>>
>> > DEPENDENCIES="
>> > :build,run? ( ... )
>> > :run? ( ... )
>> > "
>>
>> For your suggestion, consider it if we *do* fxi USE expand- via using
>> the same <namespace>:<setting> form.
>>
>> Using app-admin/mcollective ad an example, it's deps are thus:
>>
>> DEPEND="ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>> ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
>> RDEPEND="dev-ruby/stomp
>> ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>> ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
>>
>> Which, if USE_EXPAND targets were groupped, would go from this
>> ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>> ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
>> dep:run? ( dev-ruby/stomp )"
>>
>> to this:
>> ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
>> ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
>> :run? ( dev-ruby/stomp )
>
> Ok, now I get it. I've read the other threads as well, but failed to put it
> all together. Happens when you barely sleep every night :-)
>
> I don't like this mix of dependency types and use flag deps. It smells
> trouble. Dependency types should be easy to separate and read, but the above
> example is a mess, "dep:" or no "dep:".
>
> Why? Because you have to scan the whole thing to sort out which lines are
> dependency types and which lines are use deps and even then it would be easy
> to misread something.
>
> If we want to stay away from labels (which aren't that bad IMO), I'd
> recommend the following instead:
>
> Force explicit setting of the dependency type and disallow the mix of
> dependency types and use flag deps at the same level / block.
>
> DEPENDENCIES="
> :build,run? ( lib/foo )
> :run? (
> lib/bar
> someuseflag? ( random/app )
> )
> :*? (
> thing? (
> :build? ( lib/thing )
> :run? ( lib/thingrunner )
> )
> "
>
> Or, using your example:
>
> :build,run? (
>
>
> ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
> ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
> )
> :run? ( dev-ruby/stomp )
>
> Alex | wired

Or, even easier and more straightforward: just keep using *DEPEND. The
case hasn't been made yet why we need to change that in the first
place.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 09-17-2012, 12:41 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Mon, 17 Sep 2012 19:49:12 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> Or, even easier and more straightforward: just keep using *DEPEND. The
> case hasn't been made yet why we need to change that in the first
> place.

We're looking at something like eight *DEPEND variables in EAPI 6, with
considerable overlap between them all.

--
Ciaran McCreesh
 
Old 09-17-2012, 01:48 PM
Ben de Groot
 
Default GLEP: gentoo sync based unified deps proposal

On 17 September 2012 20:41, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 17 Sep 2012 19:49:12 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>> Or, even easier and more straightforward: just keep using *DEPEND. The
>> case hasn't been made yet why we need to change that in the first
>> place.
>
> We're looking at something like eight *DEPEND variables in EAPI 6, with
> considerable overlap between them all.

And like now, in the great majority of cases, only two or three will be used.
The enormous cost of moving to a different system (or the folly of using
two systems in parallel) is not worth the slight benefit of a more cosmetic
handling of the few cases where a few more *DEPEND variables would be
needed and/or there is some overlap to be dealt with.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 09-17-2012, 01:58 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Mon, 17 Sep 2012 21:48:07 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> On 17 September 2012 20:41, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Mon, 17 Sep 2012 19:49:12 +0800
> > Ben de Groot <yngwin@gentoo.org> wrote:
> >> Or, even easier and more straightforward: just keep using *DEPEND.
> >> The case hasn't been made yet why we need to change that in the
> >> first place.
> >
> > We're looking at something like eight *DEPEND variables in EAPI 6,
> > with considerable overlap between them all.
>
> And like now, in the great majority of cases, only two or three will
> be used.

And even now, people are using COMMON_DEPEND to work around *DEPEND
duplication.

--
Ciaran McCreesh
 
Old 09-17-2012, 02:11 PM
Ben de Groot
 
Default GLEP: gentoo sync based unified deps proposal

On 17 September 2012 21:58, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 17 Sep 2012 21:48:07 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>> On 17 September 2012 20:41, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> > On Mon, 17 Sep 2012 19:49:12 +0800
>> > Ben de Groot <yngwin@gentoo.org> wrote:
>> >> Or, even easier and more straightforward: just keep using *DEPEND.
>> >> The case hasn't been made yet why we need to change that in the
>> >> first place.
>> >
>> > We're looking at something like eight *DEPEND variables in EAPI 6,
>> > with considerable overlap between them all.
>>
>> And like now, in the great majority of cases, only two or three will
>> be used.
>
> And even now, people are using COMMON_DEPEND to work around *DEPEND
> duplication.

Yes, and that works just fine. I don't see what's wrong with that...

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 09-17-2012, 02:14 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Mon, 17 Sep 2012 22:11:59 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> > And even now, people are using COMMON_DEPEND to work around *DEPEND
> > duplication.
>
> Yes, and that works just fine. I don't see what's wrong with that...

Well perhaps you should read Brian's lengthy explanation that started
this thread, then.

--
Ciaran McCreesh
 
Old 09-17-2012, 02:22 PM
Michael Mol
 
Default GLEP: gentoo sync based unified deps proposal

On Mon, Sep 17, 2012 at 9:48 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 17 September 2012 20:41, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Mon, 17 Sep 2012 19:49:12 +0800
>> Ben de Groot <yngwin@gentoo.org> wrote:
>>> Or, even easier and more straightforward: just keep using *DEPEND. The
>>> case hasn't been made yet why we need to change that in the first
>>> place.
>>
>> We're looking at something like eight *DEPEND variables in EAPI 6, with
>> considerable overlap between them all.
>
> And like now, in the great majority of cases, only two or three will be used.
> The enormous cost of moving to a different system (or the folly of using
> two systems in parallel) is not worth the slight benefit of a more cosmetic
> handling of the few cases where a few more *DEPEND variables would be
> needed and/or there is some overlap to be dealt with.

As someone who's been reading these threads, but hasn't actually
written any ebuilds from scratch, I'd like to offer my perspective as
a well-intentioned beginner:

On labels: The labels, to me, appeared largely more readable (and less
formidable a syntax to read and write as a human) than the foo? (
bar/baz ) syntax...until someone demonstrated a distinction between
depends and dependency types. I hadn't even noticed a distinction
between the two, until that point was raised.

While I like the labels (to me, they feel similar to Makefiles or C
switch statements), a clearer distinction between dependencies and
dependency types would be nice.

On unified DEPENDS vs *DEPEND: It seems to me that at a code level,
there's no real semantic difference. Since they both parse out
losslessly to the same abstract thing, you could serialize that
abstract thing back out into either format. Given most cases will be
simple, you could even serialize it away into something not
bash-based, if desired. All this means, to me, that the behavior of
the two under the hood is essentially irrelevant, and any bugs in
complex implementation could be caught with automated testing.

I personally favor a singular 'DEPENDS', because

1) I feel it would lead to better-organized documentation (I'm looking
for details about one var, rather than two or three vars--oh and then
there's the other N *DEPENDS I may not even have heard of yet), and

2) I worry less about accidental namespace pollution in my make.conf
file. Why do I worry about namespace pollution? Rather than using
profiles, I have around 40-50 USE flags divided by category into
varnames like SYS_USE_COMPRESION, and then I have a line that says
USE="${SYS_USE_CPU} ${SYS_USE_COMPRESSION} ${SYS_USE_DONOTWANT} # etc"
which coalesces it all. When I ran into a strange problem some time
back, someone assisting me initially suspected that my SYS_USE_* vars
might be conflicting with something internal to portage.

Again, this isn't coming from a seasoned developer, this is coming
from a well-intentioned beginner with very little time on his hands.
--
:wq
 
Old 09-17-2012, 02:51 PM
Ben de Groot
 
Default GLEP: gentoo sync based unified deps proposal

On 17 September 2012 22:14, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 17 Sep 2012 22:11:59 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>> > And even now, people are using COMMON_DEPEND to work around *DEPEND
>> > duplication.
>>
>> Yes, and that works just fine. I don't see what's wrong with that...
>
> Well perhaps you should read Brian's lengthy explanation that started
> this thread, then.

If you mean the email that started this thread, that was neither
lengthy nor explanatory. If you mean the GLEP, that is indeed lengthy,
but mostly goes into the mechanism. It doesn't go into the rationale
to any degree of satisfaction. It doesn't make at all clear why the
supposed benefits would outweigh the costs of such a big change.

If I missed any such explanation among the myriad of related threads,
then please be so kind to link to it.
--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 09-18-2012, 04:04 AM
Arfrever Frehtes Taifersar Arahesis
 
Default GLEP: gentoo sync based unified deps proposal

A potential dev-libs/dep package might have valid use case for USE flags related to USE_EXPAND="DEP".
Your suggested syntax for types of dependencies in DEPENDENCIES would conflict with these USE flags
after implementing ":" delimiter for USE_EXPAND-related USE flags.

I vote for a separate syntax for types of dependencies.

--
Arfrever Frehtes Taifersar Arahesis
 
Old 09-18-2012, 06:48 AM
hasufell
 
Default GLEP: gentoo sync based unified deps proposal

I am unsure if that does or could solve the problem why GLEP 62 was
created, meaning... would enabling the "foo" useflag after the package
has been emerged trigger a remerge in the following example?

DEPENDENCIES="
dep:run? (
foo? ( dev-libs/foobar )
)"
 

Thread Tools




All times are GMT. The time now is 12:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org