From: Brian Harring <ferringb@gmail.com>
To: Micha?? G??rny <mgorny@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org, axs@gentoo.org
Subject: Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
Date: Sun, 16 Sep 2012 06:38:36 -0700 [thread overview]
Message-ID: <20120916133836.GB23030@localhost> (raw)
In-Reply-To: <20120916140224.31f01ccb@pomiocik.lan>
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@gmail.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@gmail.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
next prev parent reply other threads:[~2012-09-16 13:40 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 11:45 [gentoo-dev] Unified DEPENDENCIES concept Ciaran McCreesh
2012-09-07 12:29 ` Michał Górny
2012-09-07 12:36 ` Ciaran McCreesh
2012-09-07 14:23 ` Michał Górny
2012-09-07 14:53 ` Ciaran McCreesh
2012-09-07 15:02 ` Michał Górny
2012-09-07 15:07 ` Ciaran McCreesh
2012-09-07 15:16 ` Michał Górny
2012-09-07 15:25 ` Wulf C. Krueger
2012-09-07 14:50 ` Ian Stakenvicius
2012-09-07 14:58 ` Ciaran McCreesh
2012-09-07 15:46 ` Alexis Ballier
2012-09-07 16:03 ` Michał Górny
2012-09-07 16:11 ` Ian Stakenvicius
2012-09-07 16:28 ` Michael Mol
2012-09-07 16:34 ` Ciaran McCreesh
2012-09-07 16:40 ` "Paweł Hajdan, Jr."
2012-09-07 16:47 ` Ciaran McCreesh
2012-09-07 17:40 ` Alexis Ballier
2012-09-07 18:21 ` Michał Górny
2012-09-07 19:59 ` Alexis Ballier
2012-09-07 20:10 ` Michał Górny
2012-09-07 20:14 ` Ian Stakenvicius
2012-09-11 2:16 ` Brian Harring
2012-09-13 19:18 ` Kent Fredric
2012-09-13 22:17 ` Brian Harring
2012-09-15 11:06 ` Kent Fredric
2012-09-15 20:33 ` Brian Harring
2012-09-15 22:03 ` Michał Górny
2012-09-16 1:20 ` [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies Brian Harring
2012-09-16 2:39 ` Diego Elio Pettenò
2012-09-16 7:39 ` Ben de Groot
2012-09-16 13:15 ` Brian Harring
2012-09-18 22:51 ` Matt Turner
2012-09-19 4:22 ` Ben de Groot
2012-09-19 10:59 ` [gentoo-dev] " Duncan
2012-09-19 13:09 ` Michael Orlitzky
2012-09-19 13:16 ` Ian Stakenvicius
2012-09-30 22:15 ` Brian Harring
2012-10-01 0:23 ` Duncan
2012-10-02 17:47 ` Ian Stakenvicius
2012-10-03 4:00 ` Ben de Groot
2012-10-07 14:09 ` [gentoo-dev] " Steven J. Long
2012-09-16 7:56 ` [gentoo-dev] " Michał Górny
2012-09-16 11:10 ` Brian Harring
2012-09-16 11:21 ` Michał Górny
2012-09-16 11:49 ` Brian Harring
2012-09-16 12:02 ` Michał Górny
2012-09-16 13:38 ` Brian Harring [this message]
2012-09-07 16:10 ` [gentoo-dev] Unified DEPENDENCIES concept Ciaran McCreesh
2012-09-07 16:53 ` Zac Medico
2012-09-07 16:58 ` Ciaran McCreesh
2012-09-07 17:02 ` Ian Stakenvicius
2012-09-07 17:40 ` Zac Medico
2012-09-07 17:58 ` Ian Stakenvicius
2012-09-07 18:18 ` Zac Medico
2012-09-07 18:23 ` Ciaran McCreesh
2012-09-07 18:23 ` Zac Medico
2012-09-07 18:23 ` Michał Górny
2012-09-07 18:31 ` Ciaran McCreesh
2012-09-07 18:46 ` Michał Górny
2012-09-07 18:52 ` Ciaran McCreesh
2012-09-07 19:11 ` Michał Górny
2012-09-07 19:13 ` Ciaran McCreesh
2012-09-07 19:21 ` Michał Górny
2012-09-07 19:25 ` Ciaran McCreesh
2012-09-07 20:07 ` Michał Górny
2012-09-07 20:15 ` Ciaran McCreesh
2012-09-07 20:08 ` Ian Stakenvicius
2012-09-07 20:14 ` Ciaran McCreesh
2012-09-07 20:28 ` Ian Stakenvicius
2012-09-07 20:40 ` Ciaran McCreesh
2012-09-07 19:42 ` Ian Stakenvicius
2012-09-07 17:31 ` Zac Medico
2012-09-07 16:12 ` "Paweł Hajdan, Jr."
2012-09-07 16:43 ` Michał Górny
2012-09-07 22:55 ` Michael Orlitzky
2012-09-08 6:43 ` Ciaran McCreesh
2012-09-08 13:01 ` Michael Orlitzky
2012-09-08 7:27 ` Michał Górny
2012-09-08 1:02 ` Patrick Lauer
2012-09-09 3:32 ` Matt Turner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120916133836.GB23030@localhost \
--to=ferringb@gmail.com \
--cc=axs@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mgorny@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox