Mailing List Archive

Unified DEPENDENCIES concept
Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner,
and since the Exherbo documentation doesn't seem to suffice to explain
the idea here, here's some more details on the DEPENDENCIES proposal.

We observe that a typical package will have something like this:

DEPEND="
cat/first
cat/second
cat/third
cat/fourth
foo? (
foo/one
>=foo/two-2.34[monkeys]
)
bar? (
bar/one
)
baz? (
baz/one
baz/two
)
fnord? (
fnord/one
)"

RDEPEND="
cat/second
cat/third
cat/fourth
cat/fifth
foo? (
>=foo/two-2.34[monkeys]
foo/three
)
bar? (
bar/one
bar/two
bar/three
bar/four
)"

Note how many dependencies that we think of as being "the same" are
listed in two places, and are not in any way "the same".

Note also how the foo-related things, the bar-related things etc cannot
be grouped together by their fooness or barness, but are rather grouped
by their DEPENDness and RDEPENDness.

Right now we've just got three variables. In a not too distant EAPI, it
will be considerably more than three. We also have duplication; with
HDEPEND, this will sometimes become triplication.

Here's the important bit, which I shall prefix with some stars:

*** The point of DEPENDENCIES is not to replace n variables with one
*** variable.

*** The point of DEPENDENCIES is not to provide syntactic sugar over a
*** group of n variables.

*** The point of DEPENDENCIES is to allow a package's dependencies,
*** which can be very complicated, to be expressed accurately and
*** simply, in a way friendly to how developers deal with dependencies
*** in practice.

So here's what DEPENDENCIES solves:

Firstly, it allows developers to group together foo-related dependencies
and bar-related dependencies by their fooness and barness, not by their
role.

Secondly, it reduces error-prone duplication.

Thirdly, it avoids some fairly obtuse names (BADEPEND? LDEPEND?) in
favour of something a tad more readable.

Here's the other important bit, with more stars:

*** It does it by replacing the concept of "a package has build
*** dependencies, run dependencies, etc" with "a package has
*** dependencies, and each dependency is applicable at one or more of
*** build time, run tme, etc".

We could just mark each dependency individually by when it's
applicable. But that turns out to be quite verbose, since packages have
fairly long lists of dependencies of the same kind. So here's a much
more concise syntax:

DEPENDENCIES="
build:
cat/first
build+run:
cat/second
cat/third
cat/fourth
run:
cat/fifth

foo? (
build:
foo/one
build+run:
>=foo/two-2.34[monkeys]
run:
foo/three
)

bar? (
build+run:
bar/one
run:
bar/two
bar/three
bar/four
)

build:
baz? (
baz/one
baz/two
)

fnord? (
fnord/one
)"

Here are the rules for working out which labels apply to a given spec:

We have a "labels stack" when parsing. Initially, the value "build+run"
is on the top. Whenever we encounter a block ("( )", "use? ( )" etc),
we duplicate the top value of the stack, and when we leave the block we
pop the value off. Whenever we encounter labels, we replace the top
value on the stack with those labels. Whenever we encounter a spec, its
associated labels are those on the top of the stack.

To avoid weirdness, so long as we're inside a || block, use of labels
is forbidden. Note that this is a reflection of the current ambiguity
as to what DEPEND="|| ( a b )" RDEPEND="|| ( a b )" means (can you
build against a, and run against b?), and if we're wanting to tidy that
up, that should be an independent proposal.

These rules are mostly for flexibility: if developers sometimes prefer
to group things by role rather than by fooness, then that's possible
too.

The rules for eclass merging need changing too, to add a ( ) around
values rather than merely appending. This is a technicality, and isn't
developer visible.

--
Ciaran McCreesh
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 12:45:59 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner,
> and since the Exherbo documentation doesn't seem to suffice to explain
> the idea here, here's some more details on the DEPENDENCIES proposal.
>
> We observe that a typical package will have something like this:
>
> DEPEND="
> cat/first
> cat/second
> cat/third
> cat/fourth
> foo? (
> foo/one
> >=foo/two-2.34[monkeys]
> )
> bar? (
> bar/one
> )
> baz? (
> baz/one
> baz/two
> )
> fnord? (
> fnord/one
> )"
>
> RDEPEND="
> cat/second
> cat/third
> cat/fourth
> cat/fifth
> foo? (
> >=foo/two-2.34[monkeys]
> foo/three
> )
> bar? (
> bar/one
> bar/two
> bar/three
> bar/four
> )"

Now please express that using bash variable references instead of
the overly verbose expansions. Also, real examples are much more useful
than counting and monkeys. This is not mathematics.

> Note how many dependencies that we think of as being "the same" are
> listed in two places, and are not in any way "the same".
>
> Note also how the foo-related things, the bar-related things etc
> cannot be grouped together by their fooness or barness, but are
> rather grouped by their DEPENDness and RDEPENDness.

What is fooness and barness? Because I got lost near the four
non-existent word.

> Right now we've just got three variables. In a not too distant EAPI,
> it will be considerably more than three. We also have duplication;
> with HDEPEND, this will sometimes become triplication.

Sometimes != always. Sometimes HDEPEND will actually simplify
the current state. By moving a few things from DEPEND to HDEPEND, we
may be actually able to remove COMMON_DEPEND. Sometimes.

> Here's the important bit, which I shall prefix with some stars:
>
> *** The point of DEPENDENCIES is not to replace n variables with one
> *** variable.

Yes, it is.

> *** The point of DEPENDENCIES is not to provide syntactic sugar over a
> *** group of n variables.

Yes, it is.

> *** The point of DEPENDENCIES is to allow a package's dependencies,
> *** which can be very complicated, to be expressed accurately and
> *** simply, in a way friendly to how developers deal with dependencies
> *** in practice.

Didn't we already prove that the syntactic sugar DEPENDENCIES allows
can make the dependency specifications very unclear and not anywhere
close to simple?

> So here's what DEPENDENCIES solves:
>
> Firstly, it allows developers to group together foo-related
> dependencies and bar-related dependencies by their fooness and
> barness, not by their role.
>
> Secondly, it reduces error-prone duplication.

No, it doesn't. It just provides an alternate solution over how we do
that now. Does variable substitution ring a bell?

> Thirdly, it avoids some fairly obtuse names (BADEPEND? LDEPEND?) in
> favour of something a tad more readable.

That is a side effect. DEPENDENCIES doesn't disallow us from choosing
to use labels like 'd:', 'r:'. Similarly, bash variables don't anyhow
stand in the way of using more verbose names.

> Here's the other important bit, with more stars:
>
> *** It does it by replacing the concept of "a package has build
> *** dependencies, run dependencies, etc" with "a package has
> *** dependencies, and each dependency is applicable at one or more of
> *** build time, run tme, etc".

Really?

I think it actually gives concept of 'a package has a few random groups
of dependencies, where each group is applicable at one or more of build
time, run time, etc and consists of one or more dependencies or groups
of dependencies, where each group is applicable at one or more of build
time, run time, etc (which may or may not be the same as parent group)
and consists of one or more dependencies or groups of dependencies,
where each group is applicable at one or more of build time, run time,
etc (which may or may not be the same as parent group) and consists of
one or more dependencies or groups of dependencies, where each group is
applicable at one or more of build time, run time, etc (which may or
may not be the same as parent group) and consists of one or more
dependencies or groups of dependencies, where each group is applicable
at one or more of build time, run time, etc (which may or may not be
the same as parent group) and consists of one or more dependencies or
groups of dependencies, where each group is applicable at one or more
of build time, run time, etc (which may or may not be the same as
parent group) and consists ...'

> We could just mark each dependency individually by when it's
> applicable. But that turns out to be quite verbose, since packages
> have fairly long lists of dependencies of the same kind. So here's a
> much more concise syntax:
>
> DEPENDENCIES="
> build:
> cat/first
> build+run:
> cat/second
> cat/third
> cat/fourth
> run:
> cat/fifth
>
> foo? (
> build:
> foo/one
> build+run:
> >=foo/two-2.34[monkeys]
> run:
> foo/three
> )
>
> bar? (
> build+run:
> bar/one
> run:
> bar/two
> bar/three
> bar/four
> )
>
> build:
> baz? (
> baz/one
> baz/two
> )
>
> fnord? (
> fnord/one
> )"
>
> Here are the rules for working out which labels apply to a given spec:
>
> We have a "labels stack" when parsing. Initially, the value
> "build+run" is on the top. Whenever we encounter a block ("( )",
> "use? ( )" etc), we duplicate the top value of the stack, and when we
> leave the block we pop the value off. Whenever we encounter labels,
> we replace the top value on the stack with those labels. Whenever we
> encounter a spec, its associated labels are those on the top of the
> stack.

These are the rules for a machine. People don't actually read
dependencies sequentially. Provide a good algorithm which works from
any position.

> To avoid weirdness, so long as we're inside a || block, use of labels
> is forbidden. Note that this is a reflection of the current ambiguity
> as to what DEPEND="|| ( a b )" RDEPEND="|| ( a b )" means (can you
> build against a, and run against b?), and if we're wanting to tidy
> that up, that should be an independent proposal.

Yes, that's something you could work on instead of throwing a lot of
work on us just to reinvent the wheel your way because you believe that
your bicycle is much better when it has square wheels.

> These rules are mostly for flexibility: if developers sometimes prefer
> to group things by role rather than by fooness, then that's possible
> too.
>
> The rules for eclass merging need changing too, to add a ( ) around
> values rather than merely appending. This is a technicality, and isn't
> developer visible.

The algorithm you presented above was technicality as well.

So, now that your forked the thread shall we repeat all
the disadvantages which you love to forgot to mention?

--
Best regards,
Michał Górny
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 14:29:41 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > Here's the important bit, which I shall prefix with some stars:
> >
> > *** The point of DEPENDENCIES is not to replace n variables with one
> > *** variable.
>
> Yes, it is.

You've clearly either completely missed the point of all of this,
despite it being pointed out to you, or are just trying to cause
trouble. Whilst you may be thinking of a DEPENDENCIES proposal that is
about replacing n variables with one variable (and I've never seen such
a proposal being made), what we're discussing here is not that. Kindly
stay out of this discussion until you understand what it is we're
discussing.

> These are the rules for a machine. People don't actually read
> dependencies sequentially. Provide a good algorithm which works from
> any position.

Read backwards from the current position until you find a label. It's
the same algorithm you use to find out what the current section is when
you're reading an article.

> The algorithm you presented above was technicality as well.

Agreed, but it was explicitly requested by Brian, so I provided it.

> So, now that your forked the thread

...as requested by Brian...

> shall we repeat all the disadvantages which you love to forgot to
> mention?

No, please stay out of this until you understand the original proposal,
and in particular the parts marked with ***. So long as you don't
understand what we're discussing, I'm afraid any contributions you make
will simply be shouting and waving.

--
Ciaran McCreesh
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 13:36:05 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> > These are the rules for a machine. People don't actually read
> > dependencies sequentially. Provide a good algorithm which works from
> > any position.
>
> Read backwards from the current position until you find a label. It's
> the same algorithm you use to find out what the current section is
> when you're reading an article.

No, it doesn't work that way.

See:

foo? (
label:
dev-foo/bar
)
dev-bar/foo <-

Reading backwards, I find 'label'.

> > shall we repeat all the disadvantages which you love to forgot to
> > mention?
>
> No, please stay out of this until you understand the original
> proposal, and in particular the parts marked with ***. So long as you
> don't understand what we're discussing, I'm afraid any contributions
> you make will simply be shouting and waving.

What have parts marked with '***' to do with the disadvantages we have
already proved and which you didn't even bother answering?

--
Best regards,
Michał Górny
Re: Unified DEPENDENCIES concept [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/09/12 07:45 AM, Ciaran McCreesh wrote:
> [ Snip! ] Note also how the foo-related things, the bar-related
> things etc cannot be grouped together by their fooness or barness,
> but are rather grouped by their DEPENDness and RDEPENDness.
>
> [ Snip! ]
>
> So here's what DEPENDENCIES solves:
>
> Firstly, it allows developers to group together foo-related
> dependencies and bar-related dependencies by their fooness and
> barness, not by their role. [ Snip! ] *** It does it by replacing
> the concept of "a package has build *** dependencies, run
> dependencies, etc" with "a package has *** dependencies, and each
> dependency is applicable at one or more of *** build time, run tme,
> etc".

And this is the specific point that I don't like about DEPENDENCIES
versus *DEPEND. As a developer, I personally find it much more
straight-forward to fill in the deps needed for each role, rather than
specifying the role(s) that each dep will play a part in.

Although I realize that technically I could still do that (have the
dep list be role-centric rather than dep-centric), given that the
point of this change is (as stated above) to organize deps the other
way, I can't really get behind the idea.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKCcAACgkQ2ugaI38ACPDARgD+Inqa+/o1kTqlfuf7gC6wa3Da
YAmj/F7Glno1QuzALboA/1l/XCbTr27XBGv7ULcvN0rdqqrBmarA8CgsySQiZRUB
=Xwaz
-----END PGP SIGNATURE-----
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 16:23:16 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Fri, 7 Sep 2012 13:36:05 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > These are the rules for a machine. People don't actually read
> > > dependencies sequentially. Provide a good algorithm which works
> > > from any position.
> >
> > Read backwards from the current position until you find a label.
> > It's the same algorithm you use to find out what the current
> > section is when you're reading an article.
>
> No, it doesn't work that way.
>
> See:
>
> foo? (
> label:
> dev-foo/bar
> )
> dev-bar/foo <-
>
> Reading backwards, I find 'label'.

...skipping subblocks. Although the case you've given is unlikely to
be used in practice, since experience shows that given this feature,
developers use it in an easily understood manner.

> > > shall we repeat all the disadvantages which you love to forgot to
> > > mention?
> >
> > No, please stay out of this until you understand the original
> > proposal, and in particular the parts marked with ***. So long as
> > you don't understand what we're discussing, I'm afraid any
> > contributions you make will simply be shouting and waving.
>
> What have parts marked with '***' to do with the disadvantages we have
> already proved and which you didn't even bother answering?

The problem is that you're arguing against a proposal that doesn't
exist except in your head. If you'd like to read and understand the
proposal being made, which starts with understanding the bits marked
clearly with stars, and then once you've understood it, rethink and
present any issues you find with that proposal then we might have
something to discuss.

--
Ciaran McCreesh
Re: Unified DEPENDENCIES concept [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 07 Sep 2012 10:50:40 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 07/09/12 07:45 AM, Ciaran McCreesh wrote:
> > [ Snip! ] Note also how the foo-related things, the bar-related
> > things etc cannot be grouped together by their fooness or barness,
> > but are rather grouped by their DEPENDness and RDEPENDness.
> >
> > [ Snip! ]
> >
> > So here's what DEPENDENCIES solves:
> >
> > Firstly, it allows developers to group together foo-related
> > dependencies and bar-related dependencies by their fooness and
> > barness, not by their role. [ Snip! ] *** It does it by replacing
> > the concept of "a package has build *** dependencies, run
> > dependencies, etc" with "a package has *** dependencies, and each
> > dependency is applicable at one or more of *** build time, run tme,
> > etc".
>
> And this is the specific point that I don't like about DEPENDENCIES
> versus *DEPEND. As a developer, I personally find it much more
> straight-forward to fill in the deps needed for each role, rather than
> specifying the role(s) that each dep will play a part in.

Have you tried doing both? You may find you're just arguing from
familiarity, and that after having worked the other way for a few
packages, that the advantages become clearer.

The wide-spread use of hacks like COMMON_DEPEND are a pretty strong
indication that people *do* think in something closer to a
DEPENDENCIES-like fashion. In particular, I find it hard to believe
that you think "ok, so I've got a build dependency upon
>=cat/pkg-2.3[foo]" and then independently work out "ok, I've got a run
>dependency upon >=cat/pkg-2.3[foo]".

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBKC6cACgkQ96zL6DUtXhG94gCgmXP0C+nAItSnCTIMoeJHzqzK
AyYAniXFZR5mJrBtuGI10dWt0nuJFhwc
=vZBn
-----END PGP SIGNATURE-----
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 15:53:50 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Fri, 7 Sep 2012 16:23:16 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Fri, 7 Sep 2012 13:36:05 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > These are the rules for a machine. People don't actually read
> > > > dependencies sequentially. Provide a good algorithm which works
> > > > from any position.
> > >
> > > Read backwards from the current position until you find a label.
> > > It's the same algorithm you use to find out what the current
> > > section is when you're reading an article.
> >
> > No, it doesn't work that way.
> >
> > See:
> >
> > foo? (
> > label:
> > dev-foo/bar
> > )
> > dev-bar/foo <-
> >
> > Reading backwards, I find 'label'.
>
> ...skipping subblocks. Although the case you've given is unlikely to
> be used in practice, since experience shows that given this feature,
> developers use it in an easily understood manner.
>
> > > > shall we repeat all the disadvantages which you love to forgot
> > > > to mention?
> > >
> > > No, please stay out of this until you understand the original
> > > proposal, and in particular the parts marked with ***. So long as
> > > you don't understand what we're discussing, I'm afraid any
> > > contributions you make will simply be shouting and waving.
> >
> > What have parts marked with '***' to do with the disadvantages we
> > have already proved and which you didn't even bother answering?
>
> The problem is that you're arguing against a proposal that doesn't
> exist except in your head. If you'd like to read and understand the
> proposal being made, which starts with understanding the bits marked
> clearly with stars, and then once you've understood it, rethink and
> present any issues you find with that proposal then we might have
> something to discuss.

Renaming and/or reordering something doesn't change its implications.
It's just 'main disadvantage' vs 'side disadvantage'.

--
Best regards,
Michał Górny
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 17:02:57 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > The problem is that you're arguing against a proposal that doesn't
> > exist except in your head. If you'd like to read and understand the
> > proposal being made, which starts with understanding the bits marked
> > clearly with stars, and then once you've understood it, rethink and
> > present any issues you find with that proposal then we might have
> > something to discuss.
>
> Renaming and/or reordering something doesn't change its implications.
> It's just 'main disadvantage' vs 'side disadvantage'.

Well no. You've been arguing against some mysterious proposal that
doesn't exist that you think is about replacing lots of variables with
one variable. That's not what DEPENDENCIES is, and now that you've got
a proper write-up, you can try reading it, understanding it and then
seeing if you have any objections to what's actually being proposed.

--
Ciaran McCreesh
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 16:07:54 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Fri, 7 Sep 2012 17:02:57 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > The problem is that you're arguing against a proposal that doesn't
> > > exist except in your head. If you'd like to read and understand
> > > the proposal being made, which starts with understanding the bits
> > > marked clearly with stars, and then once you've understood it,
> > > rethink and present any issues you find with that proposal then
> > > we might have something to discuss.
> >
> > Renaming and/or reordering something doesn't change its
> > implications. It's just 'main disadvantage' vs 'side disadvantage'.
>
> Well no. You've been arguing against some mysterious proposal that
> doesn't exist that you think is about replacing lots of variables with
> one variable. That's not what DEPENDENCIES is, and now that you've got
> a proper write-up, you can try reading it, understanding it and then
> seeing if you have any objections to what's actually being proposed.

Ah, I forgot how the goals change *everything*. Because it's good to
kill hundreds of people for the good reasons.

--
Best regards,
Michał Górny
Re: Unified DEPENDENCIES concept [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(Just for the record, I don't care about the merits or demerits of
*DEPEND or DEPENDENCIES.)

> Ah, I forgot how the goals change *everything*. Because it's good
> to kill hundreds of people for the good reasons.

You might want to take a short break to consider if you're taking
things a bit too seriously or are at least phrasing them a little
strongly here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBKEgMACgkQnuVXRcSi+5rfbgCfRyC+mXV1NTDMt+n79q2kQtox
qjwAoMDIcoFcGdYJ9HM2gt9zSDoJp2pC
=RTIv
-----END PGP SIGNATURE-----
Re: Unified DEPENDENCIES concept [ In reply to ]
I actually do like the concept but I'm not sure we can reach consensus
about '*DEPEND vs DEPENDENCIES'; a possibility to get people used to it
could be to have two parallel EAPIs, like 6 and 6-dependencies, where
the former will keep the old style and the latter use DEPENDENCIES.

After some time has passed, it could be decided to kill the less useful
one, say in EAPI 8, and get only one 'latest' EAPI again. This decision
doesn't need to be left only to the council, but since it affects
everyone it could be a vote from all the dev community.

There is also the possibility that a consensus will never be reached
and that the two styles will have to live forever, but after all, the
EAPI concept is made for this.

Given this possibility, a debate 'I perfer *DEPEND' vs 'DEPENDENCIES are
more flexible' doesn't make much sense now. What should be discussed is
the concept itself.

For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
documentation doesn't seem to mention an equivalent label.

Alexis.
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> I actually do like the concept but I'm not sure we can reach consensus
> about '*DEPEND vs DEPENDENCIES'; a possibility to get people used to
> it could be to have two parallel EAPIs, like 6 and 6-dependencies,
> where the former will keep the old style and the latter use
> DEPENDENCIES.

With eclasses supporting both of them? That's more than crazy.

> After some time has passed, it could be decided to kill the less
> useful one, say in EAPI 8, and get only one 'latest' EAPI again. This
> decision doesn't need to be left only to the council, but since it
> affects everyone it could be a vote from all the dev community.

Why the dev community only? We have many active contributors who aren't
devs and who work hard with ebuilds. It's *their* time which will be
wasted on rewriting dependencies into new form, not yours.

> There is also the possibility that a consensus will never be reached
> and that the two styles will have to live forever, but after all, the
> EAPI concept is made for this.

I believe the correct concept is 'fork'. And that's what Exherbo did.

> Given this possibility, a debate 'I perfer *DEPEND' vs 'DEPENDENCIES
> are more flexible' doesn't make much sense now. What should be
> discussed is the concept itself.
>
> For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
> documentation doesn't seem to mention an equivalent label.

But Ciaran has just said that this isn't about the labels! It's about
a philosophy in life.

Seriously saying, this isn't about equivalent types. We can choose any
labels we like. It's all about the form in which we will do it.

--
Best regards,
Michał Górny
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier <aballier@gentoo.org> wrote:
> For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
> documentation doesn't seem to mention an equivalent label.

DEPENDENCIES is essentially independent of what label names we
introduce. I get the impression Gentoo will be bikeshedding, er, I mean
selecting shorter names for some of the labels than what Exherbo is
using. So HDEPEND could be 'host' if you like.

In any case, the reason you don't see a 'host' label on Exherbo is
because it's called 'build'. Exherbo's taken a more comprehensive
approach to handling ROOT-related dependencies -- dependency resolution
for ROOT!=/ still uses / for satisfying not-purely-runtimeish
dependencies, and then has a way of locking versions on / to versions
in ROOT. It does rely upon having a fully-ROOT-and-/-aware resolver,
though, so it may not be suitable for Gentoo.

--
Ciaran McCreesh
Re: Unified DEPENDENCIES concept [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/09/12 12:03 PM, Michał Górny wrote:
> On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier
> <aballier@gentoo.org> wrote:
>
>> I actually do like the concept but I'm not sure we can reach
>> consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
>> people used to it could be to have two parallel EAPIs, like 6 and
>> 6-dependencies, where the former will keep the old style and the
>> latter use DEPENDENCIES.
>
> With eclasses supporting both of them? That's more than crazy.
>

By the time EAPI=6* would happen we should have a git tree so we'd
just fork the tree for EAPI=6-dependencies. :)

A change like this would *NEED* a long-term test phase with a lot of
developer participation, so if we were to consider it we'd need to
fork the tree and implement/maintain it in parallel to main tree
maintenance, imo. A translation script could probably also be used to
convert *DEPEND into DEPENDENCIES automatically for any packages that
dev's aren't manually managing...

...But I digress; we're nowhere near doing this yet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKHK8ACgkQ2ugaI38ACPANNgEAg2K70CzsDPRF7MhBPRoSPtHm
ngLhrWQKqQ7+A74BTJ4BAKxDyUFnAD4ikYrGvo51Ez1FWcGXntQqyiPc/W+491l7
=8+LW
-----END PGP SIGNATURE-----
Re: Unified DEPENDENCIES concept [ In reply to ]
On 9/7/12 5:46 PM, Alexis Ballier wrote:
> I actually do like the concept but I'm not sure we can reach consensus
> about '*DEPEND vs DEPENDENCIES'

I also like at least significant parts of the DEPENDENCIES concept,
especially when we start adding more dep variables like HDEPEND.

My understanding is that COMMON_DEPEND can be easily and uniformly
expressed as build+run.

Do we have some list of pros and cons, so that the discussion can be
more focused?

> a possibility to get people used to it
> could be to have two parallel EAPIs, like 6 and 6-dependencies, where
> the former will keep the old style and the latter use DEPENDENCIES.

How about just allowing older style DEPEND/RDEPEND, but not both
DEPEND/RDEPEND and DEPENDENCIES in the same ebuild? Note that this may
interact with eclasses (which is also true for above idea I think).
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, Sep 7, 2012 at 12:11 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 07/09/12 12:03 PM, Michał Górny wrote:
>> On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier
>> <aballier@gentoo.org> wrote:
>>
>>> I actually do like the concept but I'm not sure we can reach
>>> consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
>>> people used to it could be to have two parallel EAPIs, like 6 and
>>> 6-dependencies, where the former will keep the old style and the
>>> latter use DEPENDENCIES.
>>
>> With eclasses supporting both of them? That's more than crazy.
>>
>
> By the time EAPI=6* would happen we should have a git tree so we'd
> just fork the tree for EAPI=6-dependencies. :)
>
> A change like this would *NEED* a long-term test phase with a lot of
> developer participation, so if we were to consider it we'd need to
> fork the tree and implement/maintain it in parallel to main tree
> maintenance, imo. A translation script could probably also be used to
> convert *DEPEND into DEPENDENCIES automatically for any packages that
> dev's aren't manually managing...
>
> ...But I digress; we're nowhere near doing this yet.

An intermediate form of that might be useful for auditing the tree and
finding packages which aren't expressing, e.g. RDEPENDS, but probably
should.

--
:wq
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 7 Sep 2012 12:28:31 -0400
Michael Mol <mikemol@gmail.com> wrote:
> An intermediate form of that might be useful for auditing the tree and
> finding packages which aren't expressing, e.g. RDEPENDS, but probably
> should.

RDEPEND=DEPEND was removed in EAPI 4, if that's what you mean.

--
Ciaran McCreesh
Re: Unified DEPENDENCIES concept [ In reply to ]
On 9/7/12 6:03 PM, Michał Górny wrote:
> Why the dev community only? We have many active contributors who aren't
> devs and who work hard with ebuilds. It's *their* time which will be
> wasted on rewriting dependencies into new form, not yours.

Should those contributors also vote? Do they have any formal status? Do
we have established procedures for that case?

By the way, for everyone else, there is a forums thread about this topic
here:
<http://forums.gentoo.org/viewtopic-t-935812-start-0-postdays-0-postorder-asc-highlight-.html>

I guess the contributors follow gentoo-dev, so they at least can voice
their concerns, if any.

Also, requiring a rewrite of all existing ebuilds doesn't sound like a
good idea. I think this should be designed not to require a rewrite, and
then the concern about wasted time disappears.
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 07 Sep 2012 18:12:08 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 9/7/12 5:46 PM, Alexis Ballier wrote:
> > I actually do like the concept but I'm not sure we can reach
> > consensus about '*DEPEND vs DEPENDENCIES'
>
> I also like at least significant parts of the DEPENDENCIES concept,
> especially when we start adding more dep variables like HDEPEND.
>
> My understanding is that COMMON_DEPEND can be easily and uniformly
> expressed as build+run.
>
> Do we have some list of pros and cons, so that the discussion can be
> more focused?

There's one on the wiki but I'm not sure if it's up-to-date now. I made
it on top of the previous thread.

http://wiki.gentoo.org/wiki/Future_EAPI/DEPENDENCIES_variable

--
Best regards,
Michał Górny
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 07 Sep 2012 18:40:47 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
> Also, requiring a rewrite of all existing ebuilds doesn't sound like a
> good idea. I think this should be designed not to require a rewrite,
> and then the concern about wasted time disappears.

Uh, there is no "rewriting all existing ebuilds" anywhere. I've no idea
where you got that from...

--
Ciaran McCreesh
Re: Unified DEPENDENCIES concept [ In reply to ]
On 09/07/2012 09:10 AM, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 12:46:41 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
>> For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
>> documentation doesn't seem to mention an equivalent label.
>
> DEPENDENCIES is essentially independent of what label names we
> introduce. I get the impression Gentoo will be bikeshedding, er, I mean
> selecting shorter names for some of the labels than what Exherbo is
> using. So HDEPEND could be 'host' if you like.
>
> In any case, the reason you don't see a 'host' label on Exherbo is
> because it's called 'build'. Exherbo's taken a more comprehensive
> approach to handling ROOT-related dependencies -- dependency resolution
> for ROOT!=/ still uses / for satisfying not-purely-runtimeish
> dependencies, and then has a way of locking versions on / to versions
> in ROOT. It does rely upon having a fully-ROOT-and-/-aware resolver,
> though, so it may not be suitable for Gentoo.

If you're insinuating that Portage may not have a
"fully-ROOT-and-/-aware resolver", then I can assure you that this is
not a problem. The only reason that Portage currently doesn't have "a
way of locking versions on / to versions in ROOT" is that none of the
existing EAPIs have a way to express this kind of dependency constraint.
--
Thanks,
Zacd
Re: Unified DEPENDENCIES concept [ In reply to ]
On Fri, 07 Sep 2012 09:53:46 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> If you're insinuating that Portage may not have a
> "fully-ROOT-and-/-aware resolver", then I can assure you that this is
> not a problem.

In that case, why do we need HDEPEND at all?

--
Ciaran McCreesh
Re: Unified DEPENDENCIES concept [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico <zmedico@gentoo.org>
> wrote:
>> If you're insinuating that Portage may not have a
>> "fully-ROOT-and-/-aware resolver", then I can assure you that
>> this is not a problem.
>
> In that case, why do we need HDEPEND at all?
>

We don't, actually; HDEPEND is essentially DEPEND. what we need is
TDEPEND.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKKKgACgkQ2ugaI38ACPBHFgD/Y7drSHcrEnjNuQZ2bbkLgXPh
6g1KmT4u2xljTR0WergA/jc80lQ2Zy7L3CI2Hn9kyy6cmyZ7yTHJHn5ysdAZkTbS
=kdVT
-----END PGP SIGNATURE-----
Re: Unified DEPENDENCIES concept [ In reply to ]
On 09/07/2012 09:58 AM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> If you're insinuating that Portage may not have a
>> "fully-ROOT-and-/-aware resolver", then I can assure you that this is
>> not a problem.
>
> In that case, why do we need HDEPEND at all?

With existing EAPIs, it's possible to use DEPEND for host buildtime-only
deps, RDEPEND for target build+run deps, and PDEPEND for target
runtime-only deps. However, there's no way to to specify buildtime-only
target deps (that aren't needed at runtime). The HDEPEND proposal
involves solves this by using HDEPEND for host buildtime-only deps, and
DEPEND for target buildtime-only deps.
--
Thanks,
Zac

1 2 3  View All