[gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 12:45:59 +0100
Ciaran McCreesh  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 k

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 14:29:41 +0200
Michał Górny  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


signature.asc
Description: PGP signature

[gentoo-dev] Use slot deps for all gstreamer package dependencies (including plugins); preparation for gstreamer-1.0

[Mart Raudsepp]

Hello,

The release of a new major GStreamer 1.0 release is going to happen
soon. It will be parallel-installable with the 0.10 series, so it will
be eventually introduced as a separate SLOT and co-exist for a while.

As such, if you maintain any packages that have any dependencies on

media-libs/gstreamer
media-libs/gst-plugins-*
media-plugins/gst-plugins-*

please get ready for it by pinning the dependencies to the appropriate
SLOT, which should currently be 0.10 in all cases.
Use SLOT deps if at all possible with your used EAPI, or at least a
=media-plugins/gst-plugins-foo-0.10* kind of dependency.

This way I'll have less package maintainers to chase around and bugs to
file once it's actually time to introduce the new SLOTs to the tree
(having all currently packages properly slot depend on 0.10 is
considered a blocker for 1.0 introducing).

media-libs/gst-plugins-bad used to be SLOT=0 accidentally, but this has
been slotmoved now, so SLOT 0.10 dep there as well.


Thanks,
Mart Raudsepp

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 13:36:05 +0100
Ciaran McCreesh  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-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: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 16:23:16 +0200
Michał Górny  wrote:
> On Fri, 7 Sep 2012 13:36:05 +0100
> Ciaran McCreesh  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 10:50:40 -0400
Ian Stakenvicius  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: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 15:53:50 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 16:23:16 +0200
> Michał Górny  wrote:
> > On Fri, 7 Sep 2012 13:36:05 +0100
> > Ciaran McCreesh  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 17:02:57 +0200
Michał Górny  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 16:07:54 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 17:02:57 +0200
> Michał Górny  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Wulf C. Krueger]

-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: [gentoo-dev] Unified DEPENDENCIES concept

[Alexis Ballier]

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: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-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
>  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: [gentoo-dev] Unified DEPENDENCIES concept

[Paweł Hajdan, Jr.]

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).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michael Mol]

On Fri, Sep 7, 2012 at 12:11 PM, Ian Stakenvicius  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
>>  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: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 12:28:31 -0400
Michael Mol  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Paweł Hajdan, Jr.]

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:


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.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 07 Sep 2012 18:12:08 +0200
""Paweł Hajdan, Jr.""  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 07 Sep 2012 18:40:47 +0200
""Paweł Hajdan, Jr.""  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

On 09/07/2012 09:10 AM, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 12:46:41 -0300
> Alexis Ballier  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: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 07 Sep 2012 09:53:46 -0700
Zac Medico  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-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 
> 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: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Fabian Groffen]

On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote:
> #1 - there is both a specification, and an initial implementation, AND
> a fork of the tree that is kept semi-up-to-date on my dev overlay.

I was interested in a (formal) specification, not a proof of concept.

> #2 - related to your question about what the proposal solves -- in my
> opinion, the biggest thing the proposal solves is the case where we
> want the ability to use SLOTs in the tree to manage and track
> dependency changes (ie, when an API or ABI has changed), but NOT allow
> multiple versions of a package to be installed at the same time.
> Further to this, it allows PMs to determine what needs to be rebuilt
> due to the old (no longer existing) dep being supported prior to said
> dep actually being removed.

...

> sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}.
>  It doesn't have to replate to ${PV} at all, and generally shouldn't.
>  More likely it should relate to the ${major}.${minor} in the main
> library's SONAME.  For non-libtool dependencies some other form of id
> is used, ie for perl I used the major.minor from $PV.

> EAPI="4-slot-deps" is new to me; the implementation i've been testing

You refer to it lateron, so it seems to me you're unaware your sub-slots
and slot-deps are made as one commit [1].

> is EAPI="4-slot-abi" which is sub-slots and slot operators.  This is
> the spec that was written and proposed for EAPI=5 and so this is what
> i'll use to describe the above.

both are proposed for EAPI=5 [2]

> First, assuming currently libfnord is SLOT=0, and that there are no
> ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use
> the ${major} version from the SONAME for the sub-slot. IE:
> 
> libfnord-1:SLOT="0/3"
> libfnord-2:SLOT="0/5"
> libfnord-2.1:SLOT="0/5"
> ...
> libfnord-3.5:SLOT="0/5"
> 
> And then, assuming that foo and bar both link in the usual way, IE
> they link against libfnord.so.3 instead of just libfnord.so , they

SONAME indeed refers to the versioned lib, although linking is of course
done against libfnord.so (-lfnord).

> both would RDEPEND as follows:
> 
> RDEPEND="app-cat/libfnord:="

This is "Slot operator dependencies" syntax.

> > (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5
> > would be masked due to some problem not noticed prior to stabling
> > that makes it useless for many users. [2]bar-2.4 during configure
> > checks for a new function in libfnord-3.5 and uses it if available,
> > or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes
> > a crash in some function of the library. (Note: this whole
> > example/question sounds like an ebuild-quiz question that any dev
> > should be able to answer then.)
> > 
> > What would be the advantage of sub-slot here, assuming the
> > versioning of the libraries follows ABI versioning rules defined by
> > e.g. libtool.
> 
> [1] No advantage as sub-slots wouldn't relate to this, UNLESS the
> masking would then remove -all- SLOT="0/5" versions from the tree.  In
> that case, the old SLOT="0/3" provider would be the 'upgrade' path and
> so 'foo' and 'bar' would be triggered for rebuild (since the lib they
> were linked to would be disappearing during emerge -uDN)

So your example SLOTs are wrong, and should have included the minor
(always!?!) since downgrading a lib that goes back to an older minor
means functions no longer exist, thus a consumer can potentially break.

> [2] In this case, the new ABI/API offering in libfnord-3.5 would need
> to be addressed in the SLOT, ie, SLOT="0/5.12".  As such when
> libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged
> of course) would be triggered for rebuild.  'foo' would afaik also be
> triggered for rebuild, though, as (at present) there isn't a way to
> match partial sub-slots (or sub-sub-slots, as it were) via the slot
> operators := and :*.

So you basically say: this is slot-dep, you store that bar-2.4 uses
libfnord-2.1.

> [3] No advantage, as linking would be consistent.  Sub-slots wouldn't
> be needed in this case, and afaict updating libfnord-2.1 to
> libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any
> additional mediation anyways.

Yes.

> Hope this helps clear things up..

I think I understand why ciaramn suggested the use of / iso SUB_SLOT (or
something like that) here.

Could you give an example where implicit ${PV} as sub-slot would not do
what you need?

Do you allow sub-slot to depend on e.g. USE-flags in use?  Suppose
libfnord has a USE-flag cow that adds special cow interfaces to the
ABI/API.  Would SLOT="X/${PV}$(use cow && echo -- -cow)" work?
(I think SLOT is supposed to be metadata-static, but does the sub-slot
part count to that?)


[1] 
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01
[2] http://wiki.gentoo.org/wiki/EAPI_5_tentative_features

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital 

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

On 09/07/2012 09:58 AM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700
> Zac Medico  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

[gentoo-dev] On flags being in IUSE (and the prefix USE-flag in particular)

[Fabian Groffen]

All,

mgorny opened up a bug[1], which requests for all eclasses that use the
'prefix' USE-flag to be "fixed" to add 'prefix' to IUSE.

While the 'prefix' USE-flag has since its introduction belonged to that
group of USE-flags that are not supposed to be set by the user
him/herself, it is not covered by any definition claiming it is.
(Judging by PMS.)  Other flags in this category are the userland_*,
elibc_*, kernel_*, x86, amd64, etc. flags.

With the introduction of IMPLICIT_IUSE (scheduled for EAPI 5), a phrase
has been added to PMS, that finally makes a statement on what's supposed
to be in IUSE, and what not[2].  To me, this patch means that things like
userland_BSD, elibc_glibc, etc. do *NOT* belong in IUSE of an
ebuild/eclass (and hence should b removed).  'prefix', on the other
hand, should be added to IUSE of those ebuilds/eclasses that use them.

For EAPI 5 (assuming it contains IMPLICIT_IUSE) the base profile can be
enriched with IMPLICIT_IUSE="prefix".

For all currently Council approved EAPIs this means 'prefix' has to be
added to IUSE.  While said bug[1] is assigned to the prefix team, I feel
this is actually for the coordinating role, since prefix does not own
most of the ebuilds/eclasses that would need changes.

In case you wonder why this is a problem now, Portage/repoman has a rule
that USE-flags that are masked in the profiles implicitly are defined.
Since USE=prefix is masked in the base profile, for Portage this
USE-flag is always defined.  With the updated PMS documentation,
however, it is supposed to act differently.

Since this would require quite some work, I'd like to hear what the
(dev) community thinks of this, if at all, before I'll Cc all
responsible teams and maintainers to fix the eclasses, followed by
ebuilds.


[1] https://bugs.gentoo.org/show_bug.cgi?id=433894
[2] 
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=d9040ab3482af5f790368bac5d053bf1cd760ba8;hp=f9f7729c047300e1924ad768a49c660e12c2f906

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Alexis Ballier]

On Fri, 7 Sep 2012 18:03:51 +0200
Michał Górny  wrote:

> On Fri, 7 Sep 2012 12:46:41 -0300
> Alexis Ballier  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.

depstr=cat/foo

case $EAPI in
 *-dependencies) DEPENDENCIES="build+run: $depstr";;
 *) DEPEND="$depstr"
RDEPEND="$depstr";;
esac


Yes, eclasses supporting more than one EAPI is crazy and we should
create a new eclass for every EAPI :)


> > 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.

It seems we have a different definition of 'dev community'. That's true
we have well established voting procedures for gentoo devs or foundation
members, but feel free to propose one for the rest of contributors.

> > 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.

An EAPI is a fork of the ebuild API already. Exherbo is not a fork as
far as I know, or at least not more than Gentoo is a Redhat fork
because it can process rpm's.

A.

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico 
>> 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.

We could do either one (or do both, and get rid of DEPEND). In
discussions on the chromium-os-dev list [1] (people who could have been
using HDEPEND for years now), the dominant preference was to use HDEPEND
since they felt that it would require the least amount of adjustment to
existing DEPEND settings.

[1]
https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
-- 
Thanks,
Zac

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 01:13 PM, Fabian Groffen wrote:
> On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote:
>> #1 - there is both a specification, and an initial
>> implementation, AND a fork of the tree that is kept
>> semi-up-to-date on my dev overlay.
> 
> I was interested in a (formal) specification, not a proof of
> concept.
> 

Ahh..  sorry, i figured the modified slot-operator spec that Ciaran
and Zac did was considered formal.  Are you looking for a GLEP, then?
 or...


>> #2 - related to your question about what the proposal solves --
>> in my opinion, the biggest thing the proposal solves is the case
>> where we want the ability to use SLOTs in the tree to manage and
>> track dependency changes (ie, when an API or ABI has changed),
>> but NOT allow multiple versions of a package to be installed at
>> the same time. Further to this, it allows PMs to determine what
>> needs to be rebuilt due to the old (no longer existing) dep being
>> supported prior to said dep actually being removed.
> 
> ...
> 
>> sub-slots is the 'some-identifier' part of
>> ${SLOT}/${some-identifier}. It doesn't have to replate to ${PV}
>> at all, and generally shouldn't. More likely it should relate to
>> the ${major}.${minor} in the main library's SONAME.  For
>> non-libtool dependencies some other form of id is used, ie for
>> perl I used the major.minor from $PV.
> 
>> EAPI="4-slot-deps" is new to me; the implementation i've been
>> testing
> 
> You refer to it lateron, so it seems to me you're unaware your
> sub-slots and slot-deps are made as one commit [1].
> 

if you s/slot-deps/slot-operators/ , then yes i'm aware.  to me,
"slot-deps" is something we got in (iirc) EAPI=2.



>> is EAPI="4-slot-abi" which is sub-slots and slot operators.  This
>> is the spec that was written and proposed for EAPI=5 and so this
>> is what i'll use to describe the above.
> 
> both are proposed for EAPI=5 [2]
> 
>> First, assuming currently libfnord is SLOT=0, and that there are
>> no ABI/API breakages on libfnord-2 through libfnord-3.5, I would
>> just use the ${major} version from the SONAME for the sub-slot.
>> IE:
>> 
>> libfnord-1:SLOT="0/3" libfnord-2:SLOT="0/5" 
>> libfnord-2.1:SLOT="0/5" ... libfnord-3.5:SLOT="0/5"
>> 
>> And then, assuming that foo and bar both link in the usual way,
>> IE they link against libfnord.so.3 instead of just libfnord.so ,
>> they
> 
> SONAME indeed refers to the versioned lib, although linking is of
> course done against libfnord.so (-lfnord).
> 

When looking at the output of 'scanelf -n' on a binary or library,
dependent libs seem usually to be linked against libfnord.so.X rather
than libfnord.so ; hence the breakage when upgrading from a
libfnord.so.3 provider to a libfnord.so.5 provider.  I'm sure you're
aware of that, just trying to clarify what I meant above.


>> both would RDEPEND as follows:
>> 
>> RDEPEND="app-cat/libfnord:="
> 
> This is "Slot operator dependencies" syntax.
> 

...and?

>>> (numeric indicators added): [1]What if libfnord-2.1 or
>>> libfnord-3.5 would be masked due to some problem not noticed
>>> prior to stabling that makes it useless for many users.
>>> [2]bar-2.4 during configure checks for a new function in
>>> libfnord-3.5 and uses it if available, or uses an alternative
>>> code-path instead. [3]libfnord-2.1-r5 fixes a crash in some
>>> function of the library. (Note: this whole example/question
>>> sounds like an ebuild-quiz question that any dev should be able
>>> to answer then.)
>>> 
>>> What would be the advantage of sub-slot here, assuming the 
>>> versioning of the libraries follows ABI versioning rules
>>> defined by e.g. libtool.
>> 
>> [1] No advantage as sub-slots wouldn't relate to this, UNLESS
>> the masking would then remove -all- SLOT="0/5" versions from the
>> tree.  In that case, the old SLOT="0/3" provider would be the
>> 'upgrade' path and so 'foo' and 'bar' would be triggered for
>> rebuild (since the lib they were linked to would be disappearing
>> during emerge -uDN)
> 
> So your example SLOTs are wrong, and should have included the
> minor (always!?!) since downgrading a lib that goes back to an
> older minor means functions no longer exist, thus a consumer can
> potentially break.
> 

If those (missing) functions are necessary then the either the full
slot, or the particular minimum package version, of libfnord would
need to be specified in the consumer.  This isn't any different from
how things work now.

IE, if foo works fine when being built against either libfnord-1 or
libfnord-2 , then the := slot operator will trigger a rebuild when
libfnord upgrades or downgrades.  That's its point.  If foo needs
functions that only libfnord-2 provides then it needs a dep of
> =libfnord-2 , or alternatively libfnord:0/5 .


>> [2] In this case, the new ABI/API offering in libfnord-3.5 would
>> need to be addressed in the SLOT, ie, SLOT="0/5.12".  As such
>> when libfnord-3.5 would be upgraded then bar-2.4 (if it w

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2012 10:13 AM, Fabian Groffen wrote:
> Could you give an example where implicit ${PV} as sub-slot would
> not do what you need?

Can you point out a package for which SONAME/ABI/whatever changes
every time ${PV} changes? Probably not. Is the relationship between
${PV} and SONAME/ABI/whatever changes the same for every package?
Absolutely not. So, we have to be able to bump the sub-slot when it's
appropriate for the particular package, and every package is different.
- -- 
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKNEoACgkQ/ejvha5XGaOvAQCfZS/TAtDijXFox9cHi3BkjKgP
raYAoJL77bi09/dABH3brj+2LjWYbydK
=sIAY
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 01:40 PM, Zac Medico wrote:
> On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
>> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
>>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico
>>>  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.
> 
> We could do either one (or do both, and get rid of DEPEND). In 
> discussions on the chromium-os-dev list [1] (people who could have
> been using HDEPEND for years now), the dominant preference was to
> use HDEPEND since they felt that it would require the least amount
> of adjustment to existing DEPEND settings.
> 
> [1] 
> https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE


Thanks
> 
for clarifying this; after reading through the bug I wasn't
sure if the recommendation was to add HDEPEND only or to deprecate
DEPEND entirely for HDEPEND/TDEPEND.

Just to clarify the work involved in converting to this; since DEPEND
on EAPI<=4 is essentially HDEPEND , wouldn't migration to the new EAPI
(with HDEPEND/DEPEND) generally mean that we would need to
s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the trivial
ones)?

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

iF4EAREIAAYFAlBKNagACgkQ2ugaI38ACPD7fAD+ItO84yPGTtG5G9aY0nJvTheA
QP4CRV8euHOUeCt1CGsBAK0DbpLXnARHd6lHYCAnuihezRRYr8rO8xw7kIKmlx/U
=DkxI
-END PGP SIGNATURE-

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Fabian Groffen]

On 07-09-2012 10:52:10 -0700, Zac Medico wrote:
> On 09/07/2012 10:13 AM, Fabian Groffen wrote:
> > Could you give an example where implicit ${PV} as sub-slot would
> > not do what you need?
> 
> Can you point out a package for which SONAME/ABI/whatever changes
> every time ${PV} changes? Probably not. Is the relationship between
> ${PV} and SONAME/ABI/whatever changes the same for every package?
> Absolutely not. So, we have to be able to bump the sub-slot when it's
> appropriate for the particular package, and every package is different.

I'm sure there are such packages, but I guess you're right.  It's good
to have this clear.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

[gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

On 07-09-2012 13:51:24 -0400, Ian Stakenvicius wrote:
> On 07/09/12 01:13 PM, Fabian Groffen wrote:
> > On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote:
> >> #1 - there is both a specification, and an initial
> >> implementation, AND a fork of the tree that is kept
> >> semi-up-to-date on my dev overlay.
> > 
> > I was interested in a (formal) specification, not a proof of
> > concept.
> > 
> 
> Ahh..  sorry, i figured the modified slot-operator spec that Ciaran
> and Zac did was considered formal.  Are you looking for a GLEP, then?
>  or...

No, not a GLEP, per se.  I'm trying to understand what sub-slot does and
is.  I think I'm starting to understand now.  However, for this feature
to be added to an EAPI, IMO it would be nice if there are resources that
make it for most developers very clear how this feature should be used
(and how not), and what kind of problems it can solve.

I guess real-life examples, more extensively described than you did
before, with exactly where it goes wrong, and how the situation is
improved would help.

> if you s/slot-deps/slot-operators/ , then yes i'm aware.  to me,
> "slot-deps" is something we got in (iirc) EAPI=2.

The wiki calls it "Slot operator dependencies", which I abbreviate dto
slot-deps.  Sorry for the confusion.

> >> [1] No advantage as sub-slots wouldn't relate to this, UNLESS
> >> the masking would then remove -all- SLOT="0/5" versions from the
> >> tree.  In that case, the old SLOT="0/3" provider would be the
> >> 'upgrade' path and so 'foo' and 'bar' would be triggered for
> >> rebuild (since the lib they were linked to would be disappearing
> >> during emerge -uDN)
> > 
> > So your example SLOTs are wrong, and should have included the
> > minor (always!?!) since downgrading a lib that goes back to an
> > older minor means functions no longer exist, thus a consumer can
> > potentially break.
> 
> If those (missing) functions are necessary then the either the full
> slot, or the particular minimum package version, of libfnord would
> need to be specified in the consumer.  This isn't any different from
> how things work now.

Eh, no.  Now it just always breaks when you perform a downgrade, and
revdev-rebuild or @preserved-libs won't help you.  I prefer that you
give best practices how to use sub-slots to make Portage also able to do
a recompile of bar when libfnord in the same SLOT gets downgraded.
(Because minors are used for compatible changes -- additions -- to the
ABI.)
(And the recompile is preferably done against the headers of the
downgraded version, but with the newer version's lib still around, such
that if this is a vital binary such as Python, it will not break down --
however, this is most likely too much to ask.)

> This is why, for the rebuild of bar-2.4 to be triggered on upgrade to
> libfnord-3.5 the SLOT= var within libfnord-3.5.ebuild would need to
> have something other than SLOT="0/5", ie, SLOT="0/5.12"

Yeah, but can I also avoid bar-2.4 being recompiled when I install
libfnord-3.5?  It's not necessary, because the 5-ABI of libfnord is
supposed to be backwards compatible.  (At least that's the idea.)
Like mentioned before, I DO want bar-2.4 to be recompiled if I have to
downgrade libfnord to a version before the one I had installed when I
compiled bar-2.4, though.

> > Do you allow sub-slot to depend on e.g. USE-flags in use?  Suppose 
> > libfnord has a USE-flag cow that adds special cow interfaces to
> > the ABI/API.  Would SLOT="X/${PV}$(use cow && echo -- -cow)" work? 
> > (I think SLOT is supposed to be metadata-static, but does the
> > sub-slot part count to that?)
> 
> No, afaik slots (including sub-slots) can't be dynamic.  Plus we
> already have comprehensive use deps solutions so why would we need that?

Because the ABI changes.  But I guess you're right that we can safely
ignore packages that screw it up badly enough here.

Thanks

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2012 10:58 AM, Ian Stakenvicius wrote:
> On 07/09/12 01:40 PM, Zac Medico wrote:
>> On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
>>> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
 On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico 
  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.
> 
>> We could do either one (or do both, and get rid of DEPEND). In 
>> discussions on the chromium-os-dev list [1] (people who could
>> have been using HDEPEND for years now), the dominant preference
>> was to use HDEPEND since they felt that it would require the
>> least amount of adjustment to existing DEPEND settings.
> 
>> [1] 
>> https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
>
>> 
> 
> Thanks
> 
> for clarifying this; after reading through the bug I wasn't sure if
> the recommendation was to add HDEPEND only or to deprecate DEPEND
> entirely for HDEPEND/TDEPEND.
> 
> Just to clarify the work involved in converting to this; since
> DEPEND on EAPI<=4 is essentially HDEPEND , wouldn't migration to
> the new EAPI (with HDEPEND/DEPEND) generally mean that we would
> need to s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all
> the trivial ones)?

In the linked chromium-os-dev discussion, the consensus seemed to be
that migrating deps from DEPEND to HDEPEND would result in fewer
overall changes than migrating deps from DEPEND to TDEPEND. For this
reason, the dominant preference was to go with HDEPEND.
- -- 
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKOnQACgkQ/ejvha5XGaNguwCg01LvwyvD2AcUG2sTMdTakjuH
P4EAniQQpndputGCSLTcRB2VeZcfFhIj
=5idF
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 14:40:25 -0300
Alexis Ballier  wrote:

> On Fri, 7 Sep 2012 18:03:51 +0200
> Michał Górny  wrote:
> 
> > On Fri, 7 Sep 2012 12:46:41 -0300
> > Alexis Ballier  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.
> 
> depstr=cat/foo
> 
> case $EAPI in
>  *-dependencies) DEPENDENCIES="build+run: $depstr";;
>  *) DEPEND="$depstr"
> RDEPEND="$depstr";;
> esac

Yes, we have many eclasses where this is actually the only expected
result. Maybe start with python.eclass, that should be quite an extreme
example.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 07 Sep 2012 13:58:00 -0400
Ian Stakenvicius  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 07/09/12 01:40 PM, Zac Medico wrote:
> > On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
> >> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
> >>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico
> >>>  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.
> > 
> > We could do either one (or do both, and get rid of DEPEND). In 
> > discussions on the chromium-os-dev list [1] (people who could have
> > been using HDEPEND for years now), the dominant preference was to
> > use HDEPEND since they felt that it would require the least amount
> > of adjustment to existing DEPEND settings.
> > 
> > [1] 
> > https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
> 
> 
> Thanks
> > 
> for clarifying this; after reading through the bug I wasn't
> sure if the recommendation was to add HDEPEND only or to deprecate
> DEPEND entirely for HDEPEND/TDEPEND.
> 
> Just to clarify the work involved in converting to this; since DEPEND
> on EAPI<=4 is essentially HDEPEND , wouldn't migration to the new EAPI
> (with HDEPEND/DEPEND) generally mean that we would need to
> s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the trivial
> ones)?

I can't agree unless I am missing something. Doesn't the majority of
ebuilds actually require most of DEPEND (well, the part common with
RDEPEND) to be installed on the target? I'm thinking of the shared
libraries mostly.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2012 11:18 AM, Zac Medico wrote:
> On 09/07/2012 10:58 AM, Ian Stakenvicius wrote:
>> On 07/09/12 01:40 PM, Zac Medico wrote:
>>> On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
 On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico 
>  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.
> 
>>> We could do either one (or do both, and get rid of DEPEND). In
>>>  discussions on the chromium-os-dev list [1] (people who could 
>>> have been using HDEPEND for years now), the dominant
>>> preference was to use HDEPEND since they felt that it would
>>> require the least amount of adjustment to existing DEPEND
>>> settings.
> 
>>> [1] 
>>> https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
>
>>> 
>>> 
> 
>> Thanks
> 
>> for clarifying this; after reading through the bug I wasn't sure
>> if the recommendation was to add HDEPEND only or to deprecate
>> DEPEND entirely for HDEPEND/TDEPEND.
> 
>> Just to clarify the work involved in converting to this; since 
>> DEPEND on EAPI<=4 is essentially HDEPEND , wouldn't migration to 
>> the new EAPI (with HDEPEND/DEPEND) generally mean that we would 
>> need to s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie
>> all the trivial ones)?
> 
> In the linked chromium-os-dev discussion, the consensus seemed to
> be that migrating deps from DEPEND to HDEPEND would result in
> fewer overall changes than migrating deps from DEPEND to TDEPEND.
> For this reason, the dominant preference was to go with HDEPEND.

Also, if the HDEPEND proposal is accepted, then I would recommend to
treat the migration of dependencies to HDEPEND as entirely optional.
This is similar to the approach that we took with the introduction of
prefix support in EAPI 3, where EAPI 3 ebuilds were not obligated to
support prefix.
- -- 
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKO6cACgkQ/ejvha5XGaOTVwCfUTyG5yHC6PIoBpsUhWvD874U
bBcAmwfhVLRWRwDBWfI2LvFTdXUY0q7y
=0a/L
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ciaran McCreesh]

On Fri, 7 Sep 2012 20:17:17 +0200
Fabian Groffen  wrote:
> Eh, no.  Now it just always breaks when you perform a downgrade, and
> revdev-rebuild or @preserved-libs won't help you.  I prefer that you
> give best practices how to use sub-slots to make Portage also able to
> do a recompile of bar when libfnord in the same SLOT gets downgraded.
> (Because minors are used for compatible changes -- additions -- to the
> ABI.)

Downgrades aren't covered by sub-slots, slots, regular dependencies,
libtool, or anything else.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 11:18:28 -0700
Zac Medico  wrote:
> In the linked chromium-os-dev discussion, the consensus seemed to be
> that migrating deps from DEPEND to HDEPEND would result in fewer
> overall changes than migrating deps from DEPEND to TDEPEND. For this
> reason, the dominant preference was to go with HDEPEND.

They're looking at "minimum number of changes to make it appear to
work", not "minimum number of changes to express dependencies
correctly".

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

iEYEARECAAYFAlBKO44ACgkQ96zL6DUtXhHGDwCgi66mZCVH0UWdB8yfJxl8lcuR
QPkAnRgziWGLpMbJ1i92CXjRJ1Q2tWzJ
=S+jv
-END PGP SIGNATURE-

Re: [gentoo-dev] On flags being in IUSE (and the prefix USE-flag in particular)

[Michał Górny]

On Fri, 7 Sep 2012 19:32:12 +0200
Fabian Groffen  wrote:

> mgorny opened up a bug[1], which requests for all eclasses that use
> the 'prefix' USE-flag to be "fixed" to add 'prefix' to IUSE.

Please do not suggest that I am the one requesting this to be "fixed".
I just have opened the bug because Ciaran failed to do that aside to
complaining on the new eclasses on mailing list.

> For all currently Council approved EAPIs this means 'prefix' has to be
> added to IUSE.  While said bug[1] is assigned to the prefix team, I
> feel this is actually for the coordinating role, since prefix does
> not own most of the ebuilds/eclasses that would need changes.

To be more exact, I just wanted the Prefix team to decide on how we
should go with it, and how should new eclasses use the prefix flag.

> [1] https://bugs.gentoo.org/show_bug.cgi?id=433894

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 20:23:23 +0200
Michał Górny  wrote:
> I can't agree unless I am missing something. Doesn't the majority of
> ebuilds actually require most of DEPEND (well, the part common with
> RDEPEND) to be installed on the target? I'm thinking of the shared
> libraries mostly.

"The part common with RDEPEND" is a different issue. We're talking
about what the usual thing to do is for dependencies that are in
DEPEND but not RDEPEND. A typical example here is a binary that is
executed as part of the build process.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 02:17 PM, Fabian Groffen wrote:
> 
> No, not a GLEP, per se.  I'm trying to understand what sub-slot
> does and is.  I think I'm starting to understand now.  However, for
> this feature to be added to an EAPI, IMO it would be nice if there
> are resources that make it for most developers very clear how this
> feature should be used (and how not), and what kind of problems it
> can solve.
> 
> I guess real-life examples, more extensively described than you
> did before, with exactly where it goes wrong, and how the situation
> is improved would help.
> 

I agree; I expect devmanual.gentoo.org would need a nice big page (or
section in the SLOTs page) describing it, if not at the very least a
nice entry on wiki.g.o


 [1] No advantage as sub-slots wouldn't relate to this,
 UNLESS the masking would then remove -all- SLOT="0/5"
 versions from the tree.  In that case, the old SLOT="0/3"
 provider would be the 'upgrade' path and so 'foo' and 'bar'
 would be triggered for rebuild (since the lib they were
 linked to would be disappearing during emerge -uDN)
>>> 
>>> So your example SLOTs are wrong, and should have included the 
>>> minor (always!?!) since downgrading a lib that goes back to an 
>>> older minor means functions no longer exist, thus a consumer
>>> can potentially break.
>> 
>> If those (missing) functions are necessary then the either the
>> full slot, or the particular minimum package version, of libfnord
>> would need to be specified in the consumer.  This isn't any
>> different from how things work now.
> 
> Eh, no.  Now it just always breaks when you perform a downgrade,
> and revdev-rebuild or @preserved-libs won't help you.  I prefer
> that you give best practices how to use sub-slots to make Portage
> also able to do a recompile of bar when libfnord in the same SLOT
> gets downgraded. (Because minors are used for compatible changes --
> additions -- to the ABI.) (And the recompile is preferably done
> against the headers of the downgraded version, but with the newer
> version's lib still around, such that if this is a vital binary
> such as Python, it will not break down -- however, this is most
> likely too much to ask.)
> 

I guess maybe i'm not following your example.  To spell it out better,
here's what I'm understanding:

bar-1.0 has (prior to slot-operators) an RDEPEND="app-cat/libfnord".
No version specified.  As such, it'll build successfully against
either libfnord-1 or libfnord-2.  Right now (as i understand it) a
downgrade from libfnord-2 to libfnord-1 would "break" bar-1.0 bot
revdep-rebuild would detect and fix it.

sub-slots + slot-operators would alleviate what I just described,
auto-rebuilding bar (at least that's the theory; i've had some issues
getting portage to downgrade things even with regular slots so some
work on the implementation might be needed with this, dunno)

*IF* on the other hand, you're referring to the case of libfnord-2.1
downgrading to libfnord-2 , then yes I can see how bar-1.0 would be
broken and revdep-rebuild wouldn't fix it.  However, as far as I
understand it, proper LTVERSIONing should mean that bar wouldn't break
as anything which would break bar on a libfnord-2 downgrade shouldn't
be used by bar in libfnord-2.1 -- ie, the differences would be
internal to libfnord and not directly used by bar.

If a package is -not- properly LTVERSIONed though, sub-slot bumps
could help alleviate this issue at the ebuild level.


>> This is why, for the rebuild of bar-2.4 to be triggered on
>> upgrade to libfnord-3.5 the SLOT= var within libfnord-3.5.ebuild
>> would need to have something other than SLOT="0/5", ie,
>> SLOT="0/5.12"
> 
> Yeah, but can I also avoid bar-2.4 being recompiled when I install 
> libfnord-3.5?  It's not necessary, because the 5-ABI of libfnord
> is supposed to be backwards compatible.  (At least that's the
> idea.) Like mentioned before, I DO want bar-2.4 to be recompiled if
> I have to downgrade libfnord to a version before the one I had
> installed when I compiled bar-2.4, though.
> 

Sure -- since bar-2.4 does support a codepath for >> Do you allow sub-slot to depend on e.g. USE-flags in use?
>>> Suppose libfnord has a USE-flag cow that adds special cow
>>> interfaces to the ABI/API.  Would SLOT="X/${PV}$(use cow &&
>>> echo -- -cow)" work? (I think SLOT is supposed to be
>>> metadata-static, but does the sub-slot part count to that?)
>> 
>> No, afaik slots (including sub-slots) can't be dynamic.  Plus we 
>> already have comprehensive use deps solutions so why would we
>> need that?
> 
> Because the ABI changes.  But I guess you're right that we can
> safely ignore packages that screw it up badly enough here.

I think that the best way to resolve something like this would be more
comprehensive use dep usage -- ie, if bar uses the bits of libfnord
available through USE="cow" then bar is effectively dependant on those
bits and so a libfnord:=[cow?] dep (a

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 19:31:16 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 20:23:23 +0200
> Michał Górny  wrote:
> > I can't agree unless I am missing something. Doesn't the majority of
> > ebuilds actually require most of DEPEND (well, the part common with
> > RDEPEND) to be installed on the target? I'm thinking of the shared
> > libraries mostly.
> 
> "The part common with RDEPEND" is a different issue. We're talking
> about what the usual thing to do is for dependencies that are in
> DEPEND but not RDEPEND. A typical example here is a binary that is
> executed as part of the build process.

Thanks for keeping me on the topic.

Now, let me remind you because you probably fail to know the world
outside your dreamworld:

  (with HDEPEND/DEPEND) generally mean that we would need to
  s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the trivial
  ones)?

That does effectively refer to the common depends as well. You know, in
the real world where there is no magical variables which do miracles
behind your back.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

On 07-09-2012 19:21:57 +0100, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 20:17:17 +0200
> Fabian Groffen  wrote:
> > Eh, no.  Now it just always breaks when you perform a downgrade, and
> > revdev-rebuild or @preserved-libs won't help you.  I prefer that you
> > give best practices how to use sub-slots to make Portage also able to
> > do a recompile of bar when libfnord in the same SLOT gets downgraded.
> > (Because minors are used for compatible changes -- additions -- to the
> > ABI.)
> 
> Downgrades aren't covered by sub-slots, slots, regular dependencies,
> libtool, or anything else.

It seems I mistakenly took slot-operator-deps and sub-slots as something
that can be mapped onto ABIs.  Doing so, however has proven to be wrong.

It appears slot-operator-deps do have some resemblance with ABI here
(especially if :* would be written in PMS such that it only allows
upgrades, no downgrades), but sub-slots are completely unrelated.

I don't like the mixing of the two in a single var, at all.  I think I'd
much more prefer Portage to understand ABIs and potentially versions, to
make it explicit why it is doing what.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 20:46:48 +0200
Michał Górny  wrote:
> Now, let me remind you because you probably fail to know the world
> outside your dreamworld:
> 
>   (with HDEPEND/DEPEND) generally mean that we would need to
>   s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> trivial ones)?
> 
> That does effectively refer to the common depends as well. You know,
> in the real world where there is no magical variables which do
> miracles behind your back.

Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
*entirely* different case when it comes to destinations, since RDEPEND
goes to ROOT.

The distinction between DEPEND and HDEPEND is relevant only for
dependencies that are not also in RDEPEND.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ciaran McCreesh]

On Fri, 7 Sep 2012 20:49:35 +0200
Fabian Groffen  wrote:
> On 07-09-2012 19:21:57 +0100, Ciaran McCreesh wrote:
> > On Fri, 7 Sep 2012 20:17:17 +0200
> > Fabian Groffen  wrote:
> > > Eh, no.  Now it just always breaks when you perform a downgrade,
> > > and revdev-rebuild or @preserved-libs won't help you.  I prefer
> > > that you give best practices how to use sub-slots to make Portage
> > > also able to do a recompile of bar when libfnord in the same SLOT
> > > gets downgraded. (Because minors are used for compatible changes
> > > -- additions -- to the ABI.)
> > 
> > Downgrades aren't covered by sub-slots, slots, regular dependencies,
> > libtool, or anything else.
> 
> It seems I mistakenly took slot-operator-deps and sub-slots as
> something that can be mapped onto ABIs.  Doing so, however has proven
> to be wrong.

It's not entirely wrong. There's a reason we stopped using the word
"ABI", though: it's a meaningless term with a lot of misleading
connotations.

> It appears slot-operator-deps do have some resemblance with ABI here
> (especially if :* would be written in PMS such that it only allows
> upgrades, no downgrades), but sub-slots are completely unrelated.

Downgrades are a different, unrelated problem. If you're trying to
solve that, you'll need a different, orthogonal solution. Note, though,
that downgrade breakages are typically not covered by whatever you think
an ABI is.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

On 07-09-2012 14:39:38 -0400, Ian Stakenvicius wrote:
> I guess maybe i'm not following your example.  To spell it out better,
> here's what I'm understanding:
> 
> bar-1.0 has (prior to slot-operators) an RDEPEND="app-cat/libfnord".
> No version specified.  As such, it'll build successfully against
> either libfnord-1 or libfnord-2.  Right now (as i understand it) a
> downgrade from libfnord-2 to libfnord-1 would "break" bar-1.0 bot
> revdep-rebuild would detect and fix it.

right or portage would preserve libfnord-2's libs

> sub-slots + slot-operators would alleviate what I just described,
> auto-rebuilding bar (at least that's the theory; i've had some issues
> getting portage to downgrade things even with regular slots so some
> work on the implementation might be needed with this, dunno)
> 
> *IF* on the other hand, you're referring to the case of libfnord-2.1
> downgrading to libfnord-2 , then yes I can see how bar-1.0 would be
> broken and revdep-rebuild wouldn't fix it.  However, as far as I
> understand it, proper LTVERSIONing should mean that bar wouldn't break
> as anything which would break bar on a libfnord-2 downgrade shouldn't
> be used by bar in libfnord-2.1 -- ie, the differences would be
> internal to libfnord and not directly used by bar.

Well, yes and no.  The no applies to the case where bar works around a
missing function by e.g. implementing it itself, conditionally.  A
package maintainer might not have been aware of this, hence not
expressed this in the dependencies (e.g. requiring the version that
contains the missing function).
Anyway, we should avoid downgrades of libraries, so no need to discuss
this any further.  It doesn't break more than it does already.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Zac Medico]

On 09/07/2012 11:17 AM, Fabian Groffen wrote:
> No, not a GLEP, per se.  I'm trying to understand what sub-slot does and
> is.  I think I'm starting to understand now.  However, for this feature
> to be added to an EAPI, IMO it would be nice if there are resources that
> make it for most developers very clear how this feature should be used
> (and how not), and what kind of problems it can solve.
> 
> I guess real-life examples, more extensively described than you did
> before, with exactly where it goes wrong, and how the situation is
> improved would help.

Perhaps some of the greatest frustrations for Gentoo users stem from the
lack of support for automatic rebuild of packages when necessary.
Imagine how nice it would be if necessary rebuilds would automatically
occur when appropriate, so that you wouldn't experience build failures
that require you to manually intervene by running revdep-rebuild,
perl-cleaner, or something like that. And there are other kinds of
necessary rebuilds that don't trigger build failures, but lead to
runtime failures that are noticed much later (like xorg driver failures
after a major xorg-server update). Sub-slots can be used to solve the
bulk of problems like these that our users have had to deal with manually.

> Eh, no.  Now it just always breaks when you perform a downgrade, and
> revdev-rebuild or @preserved-libs won't help you.  I prefer that you
> give best practices how to use sub-slots to make Portage also able to do
> a recompile of bar when libfnord in the same SLOT gets downgraded.
> (Because minors are used for compatible changes -- additions -- to the
> ABI.)
> (And the recompile is preferably done against the headers of the
> downgraded version, but with the newer version's lib still around, such
> that if this is a vital binary such as Python, it will not break down --
> however, this is most likely too much to ask.)

It might be worthwhile to try come up with some way to handle minor
downgrades in some later EAPI, but it adds complexity. Meanwhile,
sub-slots are a relatively simple extension to slot-operator deps, and
they are poised to greatly improve user experience (via automatic
rebuilds) if they are included in EAPI 5.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

On 07-09-2012 19:55:53 +0100, Ciaran McCreesh wrote:
> > It appears slot-operator-deps do have some resemblance with ABI here
> > (especially if :* would be written in PMS such that it only allows
> > upgrades, no downgrades), but sub-slots are completely unrelated.
> 
> Downgrades are a different, unrelated problem. If you're trying to
> solve that, you'll need a different, orthogonal solution. Note, though,
> that downgrade breakages are typically not covered by whatever you think
> an ABI is.

I don't really want to solve downgrades.  I just want to fully
understand what slot-deps is supposed to do, and what not.
It seems I fail in doing so.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 19:52:05 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 20:46:48 +0200
> Michał Górny  wrote:
> > Now, let me remind you because you probably fail to know the world
> > outside your dreamworld:
> > 
> >   (with HDEPEND/DEPEND) generally mean that we would need to
> >   s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> > trivial ones)?
> > 
> > That does effectively refer to the common depends as well. You know,
> > in the real world where there is no magical variables which do
> > miracles behind your back.
> 
> Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
> *entirely* different case when it comes to destinations, since RDEPEND
> goes to ROOT.

And? RDEPEND isn't required to be merged before building the package.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 21:11:22 +0200
Michał Górny  wrote:
> On Fri, 7 Sep 2012 19:52:05 +0100
> Ciaran McCreesh  wrote:
> > On Fri, 7 Sep 2012 20:46:48 +0200
> > Michał Górny  wrote:
> > > Now, let me remind you because you probably fail to know the world
> > > outside your dreamworld:
> > > 
> > >   (with HDEPEND/DEPEND) generally mean that we would need to
> > >   s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> > > trivial ones)?
> > > 
> > > That does effectively refer to the common depends as well. You
> > > know, in the real world where there is no magical variables which
> > > do miracles behind your back.
> > 
> > Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
> > *entirely* different case when it comes to destinations, since
> > RDEPEND goes to ROOT.
> 
> And? RDEPEND isn't required to be merged before building the package.

I repeat: "things in both DEPEND and RDEPEND".

I also repeat: HDEPEND is relevant only to things that are in DEPEND
and not RDEPEND.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 20:13:19 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 21:11:22 +0200
> Michał Górny  wrote:
> > On Fri, 7 Sep 2012 19:52:05 +0100
> > Ciaran McCreesh  wrote:
> > > On Fri, 7 Sep 2012 20:46:48 +0200
> > > Michał Górny  wrote:
> > > > Now, let me remind you because you probably fail to know the
> > > > world outside your dreamworld:
> > > > 
> > > >   (with HDEPEND/DEPEND) generally mean that we would need to
> > > >   s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> > > > trivial ones)?
> > > > 
> > > > That does effectively refer to the common depends as well. You
> > > > know, in the real world where there is no magical variables
> > > > which do miracles behind your back.
> > > 
> > > Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
> > > *entirely* different case when it comes to destinations, since
> > > RDEPEND goes to ROOT.
> > 
> > And? RDEPEND isn't required to be merged before building the
> > package.
> 
> I repeat: "things in both DEPEND and RDEPEND".
> 
> I also repeat: HDEPEND is relevant only to things that are in DEPEND
> and not RDEPEND.

So... what is your issue in here, sir?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

On 07-09-2012 12:03:16 -0700, Zac Medico wrote:
> On 09/07/2012 11:17 AM, Fabian Groffen wrote:
> > I guess real-life examples, more extensively described than you did
> > before, with exactly where it goes wrong, and how the situation is
> > improved would help.
> 
> Perhaps some of the greatest frustrations for Gentoo users stem from the
> lack of support for automatic rebuild of packages when necessary.
> Imagine how nice it would be if necessary rebuilds would automatically
> occur when appropriate, so that you wouldn't experience build failures
> that require you to manually intervene by running revdep-rebuild,
> perl-cleaner, or something like that. And there are other kinds of
> necessary rebuilds that don't trigger build failures, but lead to
> runtime failures that are noticed much later (like xorg driver failures
> after a major xorg-server update). Sub-slots can be used to solve the
> bulk of problems like these that our users have had to deal with manually.

I like that!  Kudos for making it work!

I just wonder what the heck that has to do with SLOT.
This discussion has been done before in this thread, and it somehow
settled.

> ... sub-slots are a relatively simple extension to slot-operator deps,
> and they are poised to greatly improve user experience (via automatic
> rebuilds) if they are included in EAPI 5.

And we want it.  But is it a good idea to add some feature that feels
like just a hack?


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 21:21:42 +0200
Michał Górny  wrote:
> So... what is your issue in here, sir?

The issue is what Zac, Ian and I were discussing, before you jumped in
and started yelling. Repeating it for you:

We want to know, for dependencies that are in DEPEND and not RDEPEND,
whether or not most of them will become HDEPENDs, if dependencies are
being expressed properly. If that is the case, then it makes more sense
to introduce TDEPEND than HDEPEND.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ciaran McCreesh]

On Fri, 7 Sep 2012 21:25:22 +0200
Fabian Groffen  wrote:
> I like that!  Kudos for making it work!
> 
> I just wonder what the heck that has to do with SLOT.

The correct fix for "not needing to rebuild" stuff is to SLOT libraries
like crazy, and have a SLOT per thing-we-don't-call-ABI. This then
needs := dependencies, so that packages can say "and remember which
SLOT I was built against".

However, there are some packages that cannot easily be SLOTted to the
degree that we'd like. This is where sub-SLOTs come in. Given
sub-SLOTted packages dep:1/a and dep:1/b, this says "I'd like to have
slots 1a and 1b, but it's too difficult to allow 1a and 1b to be
installed at the same time".

So suppose the user has pkg with a dependency upon dep, with slot 1 and
a := operator. They install pkg when dep:1/a is installed. The user
then installs dep:1/b. In an ideal world, dep:1/a would remain
installed in parallel with dep:1/b, but your friendly Gentoo developers
have decided it's not worth their time to allow this. Thus, dep:1/a has
to be uninstalled to allow dep:1/b to be installed. But this would
break pkg, since pkg needs dep:1/a. However, a clever dependency
resolver can note that reinstalling pkg would fix it, since dep:1/b
also satisfies pkg's slot 1 := dependency (but not the locked 1/a
dependency that the installed version of pkg has picked up).

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 02:46 PM, Michał Górny wrote:
> On Fri, 7 Sep 2012 19:31:16 +0100 Ciaran McCreesh
>  wrote:
> 
>> On Fri, 7 Sep 2012 20:23:23 +0200 Michał Górny
>>  wrote:
>>> I can't agree unless I am missing something. Doesn't the
>>> majority of ebuilds actually require most of DEPEND (well, the
>>> part common with RDEPEND) to be installed on the target? I'm
>>> thinking of the shared libraries mostly.
>> 
>> "The part common with RDEPEND" is a different issue. We're
>> talking about what the usual thing to do is for dependencies that
>> are in DEPEND but not RDEPEND. A typical example here is a binary
>> that is executed as part of the build process.
> 
> Thanks for keeping me on the topic.
> 
> Now, let me remind you because you probably fail to know the world 
> outside your dreamworld:
> 
> (with HDEPEND/DEPEND) generally mean that we would need to 
> s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> trivial ones)?
> 
> That does effectively refer to the common depends as well. You
> know, in the real world where there is no magical variables which
> do miracles behind your back.
> 

RDEPEND is defined in an earlier post (by Zac i think?) as target
build+run dependencies; there are very few actual target build-only
dependencies (ie, deps that need to be installed on the target and
don't need to be installed on the host, and don't need to be on the
target after build time).  As such, HDEPEND since it means build-host
build-time deps will still need to have these common dependencies
specified but that doesn't have anything to do with the target's
requirements, which right now are already entirely covered by RDEPEND
(and not DEPEND) at all.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKTg0ACgkQ2ugaI38ACPBZJwD9E9MT2ZVsKtY+VujuMYjhi5EC
B0RfyRnpXHu4JraBh+0A/014AWaOO3x70axEfdzTFbygRepDe6LWPqFy71nxBC3v
=7hsL
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

On 07-09-2012 20:36:02 +0100, Ciaran McCreesh wrote:
> The correct fix for "not needing to rebuild" stuff is to SLOT libraries
> like crazy, and have a SLOT per thing-we-don't-call-ABI. This then
> needs := dependencies, so that packages can say "and remember which
> SLOT I was built against".
> 
> However, there are some packages that cannot easily be SLOTted to the
> degree that we'd like. This is where sub-SLOTs come in. Given
> sub-SLOTted packages dep:1/a and dep:1/b, this says "I'd like to have
> slots 1a and 1b, but it's too difficult to allow 1a and 1b to be
> installed at the same time".
> 
> So suppose the user has pkg with a dependency upon dep, with slot 1 and
> a := operator. They install pkg when dep:1/a is installed. The user
> then installs dep:1/b. In an ideal world, dep:1/a would remain
> installed in parallel with dep:1/b, but your friendly Gentoo developers
> have decided it's not worth their time to allow this. Thus, dep:1/a has
> to be uninstalled to allow dep:1/b to be installed. But this would
> break pkg, since pkg needs dep:1/a. However, a clever dependency
> resolver can note that reinstalling pkg would fix it, since dep:1/b
> also satisfies pkg's slot 1 := dependency (but not the locked 1/a
> dependency that the installed version of pkg has picked up).

Thanks.  It seems we're there.  At last.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 03:25 PM, Fabian Groffen wrote:
> On 07-09-2012 12:03:16 -0700, Zac Medico wrote:
>> On 09/07/2012 11:17 AM, Fabian Groffen wrote:
>>> I guess real-life examples, more extensively described than you
>>> did before, with exactly where it goes wrong, and how the
>>> situation is improved would help.
>> 
>> Perhaps some of the greatest frustrations for Gentoo users stem
>> from the lack of support for automatic rebuild of packages when
>> necessary. Imagine how nice it would be if necessary rebuilds
>> would automatically occur when appropriate, so that you wouldn't
>> experience build failures that require you to manually intervene
>> by running revdep-rebuild, perl-cleaner, or something like that.
>> And there are other kinds of necessary rebuilds that don't
>> trigger build failures, but lead to runtime failures that are
>> noticed much later (like xorg driver failures after a major
>> xorg-server update). Sub-slots can be used to solve the bulk of
>> problems like these that our users have had to deal with
>> manually.
> 
> I like that!  Kudos for making it work!
> 
> I just wonder what the heck that has to do with SLOT. This
> discussion has been done before in this thread, and it somehow 
> settled.
> 
>> ... sub-slots are a relatively simple extension to slot-operator
>> deps, and they are poised to greatly improve user experience (via
>> automatic rebuilds) if they are included in EAPI 5.
> 
> And we want it.  But is it a good idea to add some feature that
> feels like just a hack?
> 
> 

Originally the sub-slot idea came about because one of the ways
"around" all of this broken-and-requiring-afterthefact-rebuilding was
to just make everything slotted -- so there would always be multiple
slots of everything installed -- and use slot-operators to indicate
when things should be re-emerged

Although this would work, the end result would (imo at least) be
horrible on-disk.

Sub-slots allow the main part of SLOT to still specify what's
installed on disk, while allowing PMS to identify and trigger rebuilds
for SLOT changes based on slot-operators.

I see it akin to the '-r' portion of ${PV} -- Used by portage to
trigger updates but having very little meaning to the actual version
of the package that gets installed. (ok i might be stretching it with
this)

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

iF4EAREIAAYFAlBKUK4ACgkQ2ugaI38ACPDbCAEAiG+7hQch043se8ZfDE4qC52w
79ZImWn5jazqGQDN3zsA/3B1AJR+SWxUFDHZF1LArX0r0Gd7J2madTqP0m+llxuG
=7IEF
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Alexis Ballier]

On Fri, 7 Sep 2012 20:21:03 +0200
Michał Górny  wrote:

> On Fri, 7 Sep 2012 14:40:25 -0300
> Alexis Ballier  wrote:
> 
> > On Fri, 7 Sep 2012 18:03:51 +0200
> > Michał Górny  wrote:
> > 
> > > On Fri, 7 Sep 2012 12:46:41 -0300
> > > Alexis Ballier  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.
> > 
> > depstr=cat/foo
> > 
> > case $EAPI in
> >  *-dependencies) DEPENDENCIES="build+run: $depstr";;
> >  *) DEPEND="$depstr"
> > RDEPEND="$depstr";;
> > esac
> 
> Yes, we have many eclasses where this is actually the only expected
> result. Maybe start with python.eclass, that should be quite an
> extreme example.
> 

Reference needed. You probably didn't even think more than 2 seconds
before making this claim about python.eclass, because it is not
particularly hard.

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 20:25:58 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 21:21:42 +0200
> Michał Górny  wrote:
> > So... what is your issue in here, sir?
> 
> The issue is what Zac, Ian and I were discussing, before you jumped in
> and started yelling. Repeating it for you:
> 
> We want to know, for dependencies that are in DEPEND and not RDEPEND,
> whether or not most of them will become HDEPENDs, if dependencies are
> being expressed properly. If that is the case, then it makes more
> sense to introduce TDEPEND than HDEPEND.

The only person yelling here is you. I have politely asked a question,
and then you come with your wisdom not answering it at all. And if you
haven't noticed, my question was directed to Ian who -- unlike you --
may be able to say something meaningful in the topic rather than
diverging from it just to prove a random point only you know.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 02:52 PM, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 20:46:48 +0200 Michał Górny 
> wrote:
>> Now, let me remind you because you probably fail to know the
>> world outside your dreamworld:
>> 
>> (with HDEPEND/DEPEND) generally mean that we would need to 
>> s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the 
>> trivial ones)?
>> 
>> That does effectively refer to the common depends as well. You
>> know, in the real world where there is no magical variables which
>> do miracles behind your back.
> 
> Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an 
> *entirely* different case when it comes to destinations, since
> RDEPEND goes to ROOT.
> 
> The distinction between DEPEND and HDEPEND is relevant only for 
> dependencies that are not also in RDEPEND.
> 

Bringing it back to the issue it's solving:

Afaict, for migration:

- - DEPEND changes to HDEPEND
- - the new DEPEND now will be used for things that are *currently* in
RDEPEND and DEPEND (so that things will work) but are not actually
run-time dependencies.  Said atoms will then be removed from RDEPEND
(and not be included in the new HDEPEND either) as they aren't really
supposed to be there in the first place.

Right?

(Note, I have no idea how this will play with PDEPEND but maybe some
of the current circular dependencies will also disappear?)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKVFUACgkQ2ugaI38ACPCcbwEAr2/+lQ70jPJ0AWp+hGQUo6YG
dFxOJPOoRpBnVlipvnoBAJgQmfB5fqK6lNQB5iJghQYhqRk5KCN4SZe7/lltRviA
=xDo8
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 16:59:48 -0300
Alexis Ballier  wrote:

> On Fri, 7 Sep 2012 20:21:03 +0200
> Michał Górny  wrote:
> 
> > On Fri, 7 Sep 2012 14:40:25 -0300
> > Alexis Ballier  wrote:
> > 
> > > On Fri, 7 Sep 2012 18:03:51 +0200
> > > Michał Górny  wrote:
> > > 
> > > > On Fri, 7 Sep 2012 12:46:41 -0300
> > > > Alexis Ballier  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.
> > > 
> > > depstr=cat/foo
> > > 
> > > case $EAPI in
> > >  *-dependencies) DEPENDENCIES="build+run: $depstr";;
> > >  *) DEPEND="$depstr"
> > > RDEPEND="$depstr";;
> > > esac
> > 
> > Yes, we have many eclasses where this is actually the only expected
> > result. Maybe start with python.eclass, that should be quite an
> > extreme example.
> > 
> 
> Reference needed. You probably didn't even think more than 2 seconds
> before making this claim about python.eclass, because it is not
> particularly hard.

Hmm, didn't it used to support having python as DEPEND only?

In any case, I'm thinking more of that line. Eclasses which sometimes
add RDEP+DEP, sometimes DEP only, and sometimes do even crazier things.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 04:10 PM, Michał Górny wrote:
> On Fri, 7 Sep 2012 16:59:48 -0300 Alexis Ballier
>  wrote:
> 
>> On Fri, 7 Sep 2012 20:21:03 +0200 Michał Górny
>>  wrote:
>> 
>>> On Fri, 7 Sep 2012 14:40:25 -0300 Alexis Ballier
>>>  wrote:
>>> 
 On Fri, 7 Sep 2012 18:03:51 +0200 Michał Górny
  wrote:
 
> On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier
>  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.
 
 depstr=cat/foo
 
 case $EAPI in *-dependencies) DEPENDENCIES="build+run:
 $depstr";; *) DEPEND="$depstr" RDEPEND="$depstr";; esac
>>> 
>>> Yes, we have many eclasses where this is actually the only
>>> expected result. Maybe start with python.eclass, that should be
>>> quite an extreme example.
>>> 
>> 
>> Reference needed. You probably didn't even think more than 2
>> seconds before making this claim about python.eclass, because it
>> is not particularly hard.
> 
> Hmm, didn't it used to support having python as DEPEND only?
> 
> In any case, I'm thinking more of that line. Eclasses which
> sometimes add RDEP+DEP, sometimes DEP only, and sometimes do even
> crazier things.
> 

Is there anything in particular in the spec/proposal for DEPENDENCIES
that would exclude the addition of individual "build: app-cat/myatom"
"run: app-cat/myatom" deps by an eclass or eclasses?  I know the
"goal" here is to make things atom-centric, but I can't see an
implementation ever working of this that wouldn't permit the "pile-on"
of additional entries of different (or even the same) roles on
identical or near-identical atoms.

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

iF4EAREIAAYFAlBKVZkACgkQ2ugaI38ACPAdAwEAlGthSTR/jor93qpclC5Gl+Sl
82mjHm3ZObOC8Btf+SYA/AxaxCfHuWXoYKj5Ryo9CKna/7cdc1sUoV0fvacO9fja
=AoSy
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 16:08:53 -0400
Ian Stakenvicius  wrote:
> Bringing it back to the issue it's solving:
> 
> Afaict, for migration:
> 
> - - DEPEND changes to HDEPEND

If we're going by Chromium, AFAICS they're only making this change when
they find they actually need it to get the resolver to give "the right
answer", and otherwise leaving DEPEND as-is. This strikes me as being
heavily in Doing It Wrong territory.

> - - the new DEPEND now will be used for things that are *currently* in
> RDEPEND and DEPEND (so that things will work) but are not actually
> run-time dependencies.  Said atoms will then be removed from RDEPEND
> (and not be included in the new HDEPEND either) as they aren't really
> supposed to be there in the first place.

I'm not entirely sure that there are more than a handful of very
special cases that would be covered by the second point. Can anyone
provide examples?

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

iEYEARECAAYFAlBKVbQACgkQ96zL6DUtXhHcUwCfdNq3MSMyYBAx19ImoOtWFMRM
l2UAoM6DfYJOCL4tLwZ3s6Jeh/6CzBCI
=FIrN
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 22:07:30 +0200
Michał Górny  wrote:
> On Fri, 7 Sep 2012 20:25:58 +0100
> Ciaran McCreesh  wrote:
> > On Fri, 7 Sep 2012 21:21:42 +0200
> > Michał Górny  wrote:
> > > So... what is your issue in here, sir?
> > 
> > The issue is what Zac, Ian and I were discussing, before you jumped
> > in and started yelling. Repeating it for you:
> > 
> > We want to know, for dependencies that are in DEPEND and not
> > RDEPEND, whether or not most of them will become HDEPENDs, if
> > dependencies are being expressed properly. If that is the case,
> > then it makes more sense to introduce TDEPEND than HDEPEND.
> 
> The only person yelling here is you. I have politely asked a question,
> and then you come with your wisdom not answering it at all. And if you
> haven't noticed, my question was directed to Ian who -- unlike you --
> may be able to say something meaningful in the topic rather than
> diverging from it just to prove a random point only you know.

Ian and I are asking essentially the same question regarding the same
issue, and I believe you're the only interested person so far who has
had any difficulty understanding that. However, if hearing it from
someone other than me makes it easier for you to accept that there is
something to discuss, then you're welcome to pretend that everything
that I say from now on was written by someone other than me.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 04:14 PM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 16:08:53 -0400 Ian Stakenvicius
>  wrote:
>> Bringing it back to the issue it's solving:
> 
>> Afaict, for migration:
> 
>> - - DEPEND changes to HDEPEND
> 
> If we're going by Chromium, AFAICS they're only making this change
> when they find they actually need it to get the resolver to give
> "the right answer", and otherwise leaving DEPEND as-is. This
> strikes me as being heavily in Doing It Wrong territory.
> 
>> - - the new DEPEND now will be used for things that are
>> *currently* in RDEPEND and DEPEND (so that things will work) but
>> are not actually run-time dependencies.  Said atoms will then be
>> removed from RDEPEND (and not be included in the new HDEPEND
>> either) as they aren't really supposed to be there in the first
>> place.
> 
> I'm not entirely sure that there are more than a handful of very 
> special cases that would be covered by the second point. Can
> anyone provide examples?
> 

Bug 263343 , the 'fontconfig' dep for some package i wasn't able to
find easily

Bug 317337 (original HDEPEND proposal) mentions the
x11-proto/xcb-proto dep for libxcb (and i assume anything else
depending on xcb-proto)

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

iF4EAREIAAYFAlBKWPgACgkQ2ugaI38ACPDUFQEAhOF99mIqr/TXTOGFgdBdARg3
RSPlU8GQpxyEP2x9GPoA/07BSSTfoObc8COCTlpiC+RQP4zbUMwWODazNCszi/hx
=BMvQ
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 16:28:40 -0400
Ian Stakenvicius  wrote:
> >> - - the new DEPEND now will be used for things that are
> >> *currently* in RDEPEND and DEPEND (so that things will work) but
> >> are not actually run-time dependencies.  Said atoms will then be
> >> removed from RDEPEND (and not be included in the new HDEPEND
> >> either) as they aren't really supposed to be there in the first
> >> place.
> > 
> > I'm not entirely sure that there are more than a handful of very 
> > special cases that would be covered by the second point. Can
> > anyone provide examples?
> 
> Bug 263343 , the 'fontconfig' dep for some package i wasn't able to
> find easily

Do we have an explanation as to *why* fontconfig has to be on ROOT
here? Is it because $ROOT/var/cache/fontconfig needs to exist at build
time, but not at runtime? If so, is this better fixed by using a
temporary directory?

> Bug 317337 (original HDEPEND proposal) mentions the
> x11-proto/xcb-proto dep for libxcb (and i assume anything else
> depending on xcb-proto)

That's a BADEPEND.

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

iEYEARECAAYFAlBKW7cACgkQ96zL6DUtXhG0iQCfdYgzb5kFYE/fN6iTAEJriyuR
zxwAoJi0PvK7JZVqaltliyJFlCZARQRj
=Tzgv
-END PGP SIGNATURE-

Re: [gentoo-dev] ROOT, EROOT, and EPREFIX in scripts (was: relative ROOT: correct behavior when ROOT=)

[Gregory M. Turner]

On 9/6/2012 5:56 AM, Ian Stakenvicius wrote:

On 06/09/12 03:55 AM, Ulrich Mueller wrote:

On Thu, 06 Sep 2012, Gregory M Turner wrote:

${ROOT:=/} EPREFIX="@GENTOO_PORTAGE_EPREFIX@"
EROOT="${ROOT}${EPREFIX}"



When ROOT is undefined or empty, this script will assign "//foo"
to EROOT and bad things will happen in Cygwin.



Several correct-ish solutions exist, i.e., in the above we could
change the concatenation statement to read:



EROOT="${ROOT}${EPREFIX#/}"


I'd rather do it the other way around: EROOT=${ROOT%/}${EPREFIX}

Reason: EPREFIX is guaranteed to start with a slash, whereas for
ROOT I wouldn't be so sure that it always ends with one.


Not to mention that `man 5 ebuild` specifically defines EROOT to be
"${ROOT%/}${EPREFIX}/" already , so all that's needed is the removal
of the final '/' if I'm reading this correctly..


Yeah, that trailing slash is kinda sneaky because it saves the day in 
the decidedly non-pathological "normal" case where ROOT is undefined and 
EPREFIX is empty.


That's another kind-of gross inconsistency that crops up with some 
regularity.  In portage python code, EROOT does, indeed, always end in a 
slash, just as man 5 ebuild specifies.


But in some places, i.e., in eselect, EROOT does not to end in a slash, 
or even has trailing slashes stripped from it.  In the case of eselect 
(which I'm just using as an example), this "quirk" has a bunch of 
consumers: the eselect plugins use code like:


foo="${EROOT}"/usr/bar

which, if it were in an ebuild, would instead be properly written as:

foo="${EROOT}"usr/bar

Indeed, most ebuilds do this correctly although occasionally I've seen 
exceptions.  My overlay is for Prefix so it "lucks out" if ebuild 
authors forget this and add the slash; but if/when non-prefix cygwin 
support is resuscitated in Gentoo, all of those extra slashes need to be 
fixed "or else."


Anyhow, my point is that this tendency to effectively standardize subtly 
inconsistent usage of EROOT is pretty !@#$&*ing gross.


I'd meant to save this "argument" for a separate thread, since a) now my 
original question isn't likely to get answered and b) I might seem to be 
bitching and moaning, as I don't, yet, have any patches to share -- but 
IMO if a bunch of scripts are going to call a variable "EROOT" in 
Gentoo, it seems like a no-brainer that the variable should have the 
same meaning in all of them.


This isn't the case right now, and has led to some real-world problems, 
so my feeling is that there ought to be some official documentation 
explaining in clear, simple terms:


 o what is the idea/point behind ROOT, EPREFIX and EROOT
 o where these variables (legitimately) come from, in other words,
   when can a user or developer inject them, and when should he
   or she be retrieving them from portage (i.e.: ebuilds).
 o the circumstances under which these variables must be changed
   in-flight, especially, for relative-ROOT activation
 o how to properly cook these variables when writing a script
   that will interact with portage (specified in a way that does
   the right thing for invokers and invokees, alike).
 o any EAPI interactions with the above (don't think we have any
   yet(?) but some recent proposals seem poised to change this).

Once we have that right, it's just a matter of changing all the scripts 
to do what the official documentation says -- if we can't, then 
obviously it's back to the drawing board to fix the specification, 
lather, rinse, repeat.


I'd be happy to do this myself but I'm not sure I know all the correct 
answers to the above questions (hence my original thread topic, for 
example), nor am I 100% sure what the correct place would be to document 
this (probably the dev manual or the wiki?)


An alternative to documenting and synchronizing code would be to build a 
source-able library script to automatically handle this type of thing. 
Maybe that's overkill, or maybe it's brilliant, I'd be interested to 
hear people's opinions.  I'm pretty sure we are just talking about a 
very few lines of simple code so my gut instinct is that it's overkill 
-- but if we expect things to get more complicated in the future, then 
centralizing the code, now, could save us some hassles, down the line.


tl;dr: we should standardize EROOT, but how?

-gmt

Re: [gentoo-dev] ROOT, EROOT, and EPREFIX in scripts

[Zac Medico]

On 09/07/2012 01:50 PM, Gregory M. Turner wrote:
> Indeed, most ebuilds do this correctly although occasionally I've seen
> exceptions.  My overlay is for Prefix so it "lucks out" if ebuild
> authors forget this and add the slash; but if/when non-prefix cygwin
> support is resuscitated in Gentoo, all of those extra slashes need to be
> fixed "or else."

So, just submit patches to the relevant maintainers. If their code adds
an extra slash then it's easy to fix by replacing ${ROOT} with
${ROOT%/}, and then it will work correctly regardless of whether ${ROOT}
contains a trailing slash.
-- 
Thanks,
Zac

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michael Orlitzky]

On 09/07/2012 07:45 AM, Ciaran McCreesh 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.
> 

It seems to me that the problem this solves is just one of ontology.
It's analogous to trying to stick files named "foo", "bar", "baz",
etc. into directories named "depend", "rdepend", "hdepend", and so on.

There are a few well-known ways to organize things in a hierarchy, and
which one is most efficient depends on the categories and objects that
you have. Given the way that most software is built (see:
COMMON_DEPEND), I think DEPENDENCIES would work better than what we're
doing now, but it also seems more complex.

I think that dependencies are ultimately not hierarchical, and this
can force duplication in DEPENDENCIES as well. Has anyone considered
tagging the package atoms with a list of dependency types? For example,

  * foo/bar: ( build run host )
  * baz/one: baz? ( build )
  * baz/two, baz/three: baz? ( build run )
  ...

This would eliminate duplication of the objects (package atoms) in
favor of duplication of the categories (dependency types). Since the
package atoms are what we really care about, I think the tradeoff is
beneficial. Maintainers get to express each dependency exactly once.

Re: [gentoo-dev] On flags being in IUSE (and the prefix USE-flag in particular)

[Gregory M. Turner]

On 9/7/2012 10:32 AM, Fabian Groffen wrote:


With the introduction of IMPLICIT_IUSE (scheduled for EAPI 5), a phrase
has been added to PMS, that finally makes a statement on what's supposed
to be in IUSE, and what not[2].  To me, this patch means that things like
userland_BSD, elibc_glibc, etc. do *NOT* belong in IUSE of an
ebuild/eclass (and hence should b removed).  'prefix', on the other
hand, should be added to IUSE of those ebuilds/eclasses that use them.


What, exactly, is the difference -- the principle behind the "should"s 
above?  USE_EXPAND?  Probably more a problem of me being lazy than 
anything being wrong with it, but [2] reads like Greek to me.



For EAPI 5 (assuming it contains IMPLICIT_IUSE) the base profile can be
enriched with IMPLICIT_IUSE="prefix".

For all currently Council approved EAPIs this means 'prefix' has to be
added to IUSE.


I haven't looked into IMPLICIT_IUSE too carefully, but ... shouldn't 
this be... implicit?  Sorry, I'm being super lazy and not reading 
anything here.



In case you wonder why this is a problem now, Portage/repoman has a rule
that USE-flags that are masked in the profiles implicitly are defined.


Probably making a total ass of myself at this point but... could you 
define "defined"?  I'm guessing I'd understand how to get flags masked 
implicitly if I read the IMPLICIT_IUSE stuff?  Or do you mean "are 
defined implicitly" (in which case, again, I don't see why we'd need to 
make them explicit).



[2] 
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=d9040ab3482af5f790368bac5d053bf1cd760ba8;hp=f9f7729c047300e1924ad768a49c660e12c2f906


Apologies for these questions -- in my defense, being both lazy and 
ignorant puts me at a real disadvantage here :)


-gmt

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Patrick Lauer]

On 09/07/12 19:45, Ciaran McCreesh 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.
>
>
There's change, and there's progress.

This is change, just to have things change.

Like the /usr move, merging udev into some random package no one uses,
and some other things that people do to keep their fingers busy.


Can we please focus on progress instead?

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 07 Sep 2012 18:55:10 -0400
Michael Orlitzky  wrote:
> I think that dependencies are ultimately not hierarchical

Situations like foo? ( bar? ( || ( a ( b c ) ) ) ) do happen, so any
new syntax would have to be able to deal with that.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature