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-19-2012, 04:07 AM
Ben de Groot
 
Default GLEP: gentoo sync based unified deps proposal

On 19 September 2012 03:18, Alec Warner <antarus@gentoo.org> wrote:
> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>> Readability is more important, and there I still don't buy the
>> argument that the new syntax is better, and that any gain would
>> outweigh the cost of changing. After all, the existing variables for
>> dependency specification won't disappear, so devs would have to
>> remember both.
>
> I agree it is a con, but is it a blocker? I mean basically any change
> proposed requires know the old way, and the new way..that is how
> changes work...

Which is why changes need to have clear benefits that outweigh the
costs of change. In this case the benefits are purely cosmetic, so
they don't. Change for change' sake is not worth the effort.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 09-19-2012, 04:09 AM
Ben de Groot
 
Default GLEP: gentoo sync based unified deps proposal

On 19 September 2012 04:40, Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 21:27:17 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
>> On Tue, 18 Sep 2012 22:22:56 +0200
>> Michał Górny <mgorny@gentoo.org> wrote:
>> > On Tue, 18 Sep 2012 21:11:10 +0100
>> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> > > On Tue, 18 Sep 2012 22:06:06 +0200
>> > > Michał Górny <mgorny@gentoo.org> wrote:
>> > > > So far, I'm not sure if there was a single, complete, exact
>> > > > problem discussed which is solved by this syntax other than
>> > > > cosmetics.
>> > >
>> > > Perhaps you should read the GLEP then.
>> >
>> > Thanks for your comprehensive answer. Could you point me, please,
>> > where is there a real, current, exact problem described?
>>
>> "Motivation / Rationale"
>
> Thanks again, I can read. Now, which one is a problem which currently
> exists in Gentoo, is exactly described and is not a cosmetic problem?

There isn't one in the current GLEP.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 09-19-2012, 06:01 AM
Matt Turner
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 19 September 2012 03:18, Alec Warner <antarus@gentoo.org> wrote:
>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>> Readability is more important, and there I still don't buy the
>>> argument that the new syntax is better, and that any gain would
>>> outweigh the cost of changing. After all, the existing variables for
>>> dependency specification won't disappear, so devs would have to
>>> remember both.
>>
>> I agree it is a con, but is it a blocker? I mean basically any change
>> proposed requires know the old way, and the new way..that is how
>> changes work...
>
> Which is why changes need to have clear benefits that outweigh the
> costs of change. In this case the benefits are purely cosmetic, so
> they don't. Change for change' sake is not worth the effort.
>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin
>

I'm sorry. Are you reading the same threads that I am?

From the other thread ("example conversion of gentoo-x86 current deps
to unified dependencies"):

> 1) This unifies the existing syntax down into a collapsed form. In
> doing so, there are measurable gains across the board for PM
> efficiency and rsync alone.
>
> 2) In unifying the syntax via reusing our /existing fucking syntax/,
> we formalize the adhoc common dependency assignments devs already are
> doing in the tree.
>
> 3) In moving to a unified syntax, it positions us to easily introduce
> new dependency types without introducing more redundancy. Easier to
> add new dep types, faster to add new dep types, more efficient in
> doing so in comparison to existing approaches, and done in a fashion
> that devs can reuse existing conditionals.
>
> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based.
> Meaning you do not need to knee-jerk attack it because of some notion
> it's ciaran based/related.

I know you must have seen this (and the rest...). You've participated
in that thread.
 
Old 09-19-2012, 06:36 AM
Ulrich Mueller
 
Default GLEP: gentoo sync based unified deps proposal

>>>>> On Tue, 18 Sep 2012, Matt Turner wrote:

> From the other thread ("example conversion of gentoo-x86 current
> deps to unified dependencies"):

[Sorry, I've missed this one in the other thread, so replying here.]

>> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based.
>> Meaning you do not need to knee-jerk attack it because of some
>> notion it's ciaran based/related.

What kind of reasoning is this? Does it mean that the syntax was
deliberately changed to make it different from exherbo's?

We should accept (or reject) things based on their technical merits,
not because of ad-hominem or "not invented here" arguments.

Ulrich
 
Old 09-19-2012, 06:55 AM
Matt Turner
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, Sep 18, 2012 at 11:36 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Tue, 18 Sep 2012, Matt Turner wrote:
>
>> From the other thread ("example conversion of gentoo-x86 current
>> deps to unified dependencies"):
>
> [Sorry, I've missed this one in the other thread, so replying here.]
>
>>> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based.
>>> Meaning you do not need to knee-jerk attack it because of some
>>> notion it's ciaran based/related.
>
> What kind of reasoning is this? Does it mean that the syntax was
> deliberately changed to make it different from exherbo's?
>
> We should accept (or reject) things based on their technical merits,
> not because of ad-hominem or "not invented here" arguments.
>
> Ulrich
>

Brian was mocking how so many people reject anything Ciaran proposes
out of hand. He actually discussed the reasoning why he doesn't
actually like labels in another thread.
 
Old 09-19-2012, 07:12 AM
Ben de Groot
 
Default GLEP: gentoo sync based unified deps proposal

On 19 September 2012 14:01, Matt Turner <mattst88@gentoo.org> wrote:
> On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 19 September 2012 03:18, Alec Warner <antarus@gentoo.org> wrote:
>>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>> Readability is more important, and there I still don't buy the
>>>> argument that the new syntax is better, and that any gain would
>>>> outweigh the cost of changing. After all, the existing variables for
>>>> dependency specification won't disappear, so devs would have to
>>>> remember both.
>>>
>>> I agree it is a con, but is it a blocker? I mean basically any change
>>> proposed requires know the old way, and the new way..that is how
>>> changes work...
>>
>> Which is why changes need to have clear benefits that outweigh the
>> costs of change. In this case the benefits are purely cosmetic, so
>> they don't. Change for change' sake is not worth the effort.
>>
>> --
>> Cheers,
>>
>> Ben | yngwin
>> Gentoo developer
>> Gentoo Qt project lead, Gentoo Wiki admin
>>
>
> I'm sorry. Are you reading the same threads that I am?

You've seen me participating in those, so obviously: yes.

> From the other thread ("example conversion of gentoo-x86 current deps
> to unified dependencies"):
>
>> 1) This unifies the existing syntax down into a collapsed form. In
>> doing so, there are measurable gains across the board for PM
>> efficiency and rsync alone.

Unifying existing syntax = cosmetic

If collapsing it is beneficial for PM internals, please do so
internally while hiding it from ebuild devs.

>> 2) In unifying the syntax via reusing our /existing fucking syntax/,
>> we formalize the adhoc common dependency assignments devs already are
>> doing in the tree.

Again, cosmetic

>> 3) In moving to a unified syntax, it positions us to easily introduce
>> new dependency types without introducing more redundancy. Easier to
>> add new dep types, faster to add new dep types, more efficient in
>> doing so in comparison to existing approaches, and done in a fashion
>> that devs can reuse existing conditionals.

Again, cosmetic

Note that adding new dep types only comes up very rarely.

>> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based.
>> Meaning you do not need to knee-jerk attack it because of some notion
>> it's ciaran based/related.

Hm, yeah, so?

> I know you must have seen this (and the rest...). You've participated
> in that thread.

Indeed. So what made you wonder if I had seen that?

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 09-19-2012, 10:48 AM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

On Tue, 18 Sep 2012 16:28:59 -0700
Brian Harring <ferringb@gmail.com> wrote:

> pkg1 rdepends <-> pkg2 rdepends; this is a contained cycle, and is
> mergable.

Do you have maybe a quick tool which could find those cycles
in the tree for us?

> keyword there is 'usable'. Wording could be expanded, but the core
> notion is there- it just skips going over graph theory/resolver
> guts/cycles since they're not explicitly a property of dependecy
> types.

Ah, right, I didn't notice the 'usable' in DEPEND.

--
Best regards,
Michał Górny
 
Old 09-19-2012, 11:36 AM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Wed, 19 Sep 2012 12:48:00 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 16:28:59 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > pkg1 rdepends <-> pkg2 rdepends; this is a contained cycle, and is
> > mergable.
>
> Do you have maybe a quick tool which could find those cycles
> in the tree for us?

I have a sneaking suspicion that any tool that could do that wouldn't
be quick...

Having said that, if you're after a rough idea of what we're dealing
with, everything in orange deps (either directly or indirectly) upon
everything else in orange:

http://dev.exherbo.org/~ciaranm/resolution-fdp.png

(That's a small part of Gentoo, from a while back, with X not enabled.
It's far worse if X is on too.)

--
Ciaran McCreesh
 
Old 09-19-2012, 02:19 PM
Jeroen Roovers
 
Default GLEP: gentoo sync based unified deps proposal

On Wed, 19 Sep 2012 15:12:42 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> >> 1) This unifies the existing syntax down into a collapsed form. In
> >> doing so, there are measurable gains across the board for PM
> >> efficiency and rsync alone.
>
> Unifying existing syntax = cosmetic

Not *entirely* cosmetic. If only you should have seen the scores of bug
reports that got resolved by simply switching DEPEND and RDEPEND in an
ebuild. Apparently a single character difference is often easy to
miss, (perhaps especially in dealing with uppercase variables). It is
definitely easier to spot the difference between lowercase "build" and
"run", so even a cosmetic change could be beneficial if it enhanced
legibility, right?


jer
 
Old 09-19-2012, 04:11 PM
Matt Turner
 
Default GLEP: gentoo sync based unified deps proposal

On Wed, Sep 19, 2012 at 12:12 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 19 September 2012 14:01, Matt Turner <mattst88@gentoo.org> wrote:
>> On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>>> On 19 September 2012 03:18, Alec Warner <antarus@gentoo.org> wrote:
>>>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>> Readability is more important, and there I still don't buy the
>>>>> argument that the new syntax is better, and that any gain would
>>>>> outweigh the cost of changing. After all, the existing variables for
>>>>> dependency specification won't disappear, so devs would have to
>>>>> remember both.
>>>>
>>>> I agree it is a con, but is it a blocker? I mean basically any change
>>>> proposed requires know the old way, and the new way..that is how
>>>> changes work...
>>>
>>> Which is why changes need to have clear benefits that outweigh the
>>> costs of change. In this case the benefits are purely cosmetic, so
>>> they don't. Change for change' sake is not worth the effort.
>>>
>>> --
>>> Cheers,
>>>
>>> Ben | yngwin
>>> Gentoo developer
>>> Gentoo Qt project lead, Gentoo Wiki admin
>>>
>>
>> I'm sorry. Are you reading the same threads that I am?
>
> You've seen me participating in those, so obviously: yes.

So then you must have also read Brian's email detailing the metadata
savings, and allowing the PM to parse fewer things (even with
quantitative measurements!). Search your email for 'cold cache'.

[snip]

Looking at what you call cosmetic makes me think that you're
collapsing "cosmetic and a useful change" down into "cosmetic" in
order to disregard it.
 

Thread Tools




All times are GMT. The time now is 09:24 AM.

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