Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies

[Brian Harring]

On Sun, Sep 16, 2012 at 02:02:24PM +0200, Micha?? G??rny wrote:
> On Sun, 16 Sep 2012 04:49:21 -0700
> Brian Harring <ferringb@×××××.com> wrote:
>
> > On Sun, Sep 16, 2012 at 01:21:26PM +0200, Micha?? G??rny wrote:
> > > On Sun, 16 Sep 2012 04:10:01 -0700
> > > Brian Harring <ferringb@×××××.com> wrote:
> > >
> > > > On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote:
> > > > > But consider that for example Zac & AxS (correct me if I recall
> > > > > it correctly) considered making changing the meaning of RDEPEND
> > > > > to install them before the build, thus effectively making
> > > > > 'build,run' useless.
> > > >
> > > > I really am not trying to be a blatant dick to you, but this has
> > > > /zero/ relevance.  RDEPEND means "required for runtime".  That
> > > > ain't changing.  If they were discussing changing what RDEPEND
> > > > meant, then they were high, period.
> > > >
> > > > If zac/axs want to try and make the resolver install RDEPEND
> > > > before DEPEND... well, they're free to.  That doesn't change the
> > > > fact that the deps still must be specified correctly; in short,
> > > > build,run is very much relevant.
> > >
> > > I don't think we have made up our mind what *exactly* we want from
> > > deps.
> >
> > Are we now expecting deps to give us ponies or something?  We know
> > *exactly* what we want from deps, and their current definition- the
> > problem isn't the definition, it's that we don't have the forms we
> > need.
>
> No, the problem is that we think we need more than we have now.

Read what I wrote.  "we don't have the forms we need"; a more proper 
statement is "we don't have all of the forms we need".

Please read what I write, rather than just responding blindly.  You 
may have time to waste, but I don't, nor do the people on this ml need 
to see you respond 13 minutes after I send an email when you 
can't even be bothered to read the fucking content properly.


> Unless
> you're considering the whole point of this thread is cosmetics... then
> please leave that to Fedora or other people who are paid to change
> stuff just because they can.

This isn't productive; frankly it's childish.  Take it to the forums 
if you want to continue on tangents like this.


> > > Just because we have something semi-correct right now, doesn't
> > > mean that we don't want to change that.
> >
> > This is a no-op argument against the proposal: "we can't
> > change the deps because we might want to change the deps".  It's also
> > irrelevant due to the core basis of it being broken as fuck
> > (described above).
>
> What I'm trying to say is that you're making a lot of noise about
> cosmetics while we haven't even agreed on what's supposed to be inside.
> So, are we introducing this obtuse syntax for three DEPEND variables,
> of which the third is almost never used?

Reiterating the points again, and for the final time for you since you 
seem intent on riding the short bus for this particular subject:

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.

Honestly, stop wasting my (and others time) and please read this email 
full and through, including the /full thread you're blindly 
responding to/ before responding again.

There is no prive for having the fastest turn around time in 
responding to an email; not unless you consider a permenant /ignore 
and killfile addition to be a prize.

~harring