[gentoo-dev] How to handle dependencies on protocol headers?

[gentoo-dev] How to handle dependencies on protocol headers?

[Matt Turner]

Often packages depending on X11 libraries will also have to specify
the X11 libraries' proto packages in DEPEND. This is because the X11
library itself #includes files provided by the proto package. It's not
really that the X11 library depends on this at run-time, so the
protocol packages aren't specified in the RDEPEND of the libraries.

This is documented in a number of bug reports (see 379545), and it
seems that the decision is between
 - add proto package to dependency list of packages using X11 libs
 - add proto package to rdepend list of the relevant library itself

The first is more correct, I think, but it's also much more annoying.
Mesa winds up having x11-proto/inputproto in DEPEND for some long
forgotten reason, for instance.

The second option is much simpler and less error prone, but removes
the ability to depclean the proto packages.

It seems that some sort of DEPEND variable that means "I only need
this when other packages are building against me" would be useful.
Thoughts?

Matt

Re: [gentoo-dev] How to handle dependencies on protocol headers?

[Alec Warner]

On Thu, Sep 15, 2011 at 9:32 PM, Matt Turner <mattst88@gentoo.org> wrote:
> Often packages depending on X11 libraries will also have to specify
> the X11 libraries' proto packages in DEPEND. This is because the X11
> library itself #includes files provided by the proto package. It's not
> really that the X11 library depends on this at run-time, so the
> protocol packages aren't specified in the RDEPEND of the libraries.
>
> This is documented in a number of bug reports (see 379545), and it
> seems that the decision is between
>  - add proto package to dependency list of packages using X11 libs
>  - add proto package to rdepend list of the relevant library itself
>
> The first is more correct, I think, but it's also much more annoying.
> Mesa winds up having x11-proto/inputproto in DEPEND for some long
> forgotten reason, for instance.

Why is it annoying?

-A

>
> The second option is much simpler and less error prone, but removes
> the ability to depclean the proto packages.
>
> It seems that some sort of DEPEND variable that means "I only need
> this when other packages are building against me" would be useful.
> Thoughts?
>
> Matt
>
>

[gentoo-dev] Re: How to handle dependencies on protocol headers?

[Matt Turner]

On Fri, Sep 16, 2011 at 12:32 AM, Matt Turner <mattst88@gentoo.org> wrote:
> Often packages depending on X11 libraries will also have to specify
> the X11 libraries' proto packages in DEPEND. This is because the X11
> library itself #includes files provided by the proto package. It's not
> really that the X11 library depends on this at run-time, so the
> protocol packages aren't specified in the RDEPEND of the libraries.
>
> This is documented in a number of bug reports (see 379545), and it
> seems that the decision is between
>  - add proto package to dependency list of packages using X11 libs
>  - add proto package to rdepend list of the relevant library itself
>
> The first is more correct, I think, but it's also much more annoying.
> Mesa winds up having x11-proto/inputproto in DEPEND for some long
> forgotten reason, for instance.
>
> The second option is much simpler and less error prone, but removes
> the ability to depclean the proto packages.
>
> It seems that some sort of DEPEND variable that means "I only need
> this when other packages are building against me" would be useful.
> Thoughts?
>
> Matt

Another similar situation:

https://bugs.gentoo.org/show_bug.cgi?id=342393

Re: [gentoo-dev] How to handle dependencies on protocol headers?

[Matt Turner]

On Fri, Sep 16, 2011 at 12:36 AM, Alec Warner <antarus@gentoo.org> wrote:
> The first is more correct, I think, but it's also much more annoying.
> Mesa winds up having x11-proto/inputproto in DEPEND for some long
> forgotten reason, for instance.
>
> Why is it annoying?

Because the proto will have to be added as a dependency to a lot of
packages, when I think it's needed if and only if the package
(r)depends on the X11 library. Because of this, it can be quite prone
to missing dependencies.

Matt

Re: [gentoo-dev] Re: How to handle dependencies on protocol headers?

[Zac Medico]

On 09/15/2011 09:42 PM, Matt Turner wrote:
> On Fri, Sep 16, 2011 at 12:32 AM, Matt Turner <mattst88@gentoo.org> wrote:
>> Often packages depending on X11 libraries will also have to specify
>> the X11 libraries' proto packages in DEPEND. This is because the X11
>> library itself #includes files provided by the proto package. It's not
>> really that the X11 library depends on this at run-time, so the
>> protocol packages aren't specified in the RDEPEND of the libraries.
>>
>> This is documented in a number of bug reports (see 379545), and it
>> seems that the decision is between
>>  - add proto package to dependency list of packages using X11 libs
>>  - add proto package to rdepend list of the relevant library itself
>>
>> The first is more correct, I think, but it's also much more annoying.
>> Mesa winds up having x11-proto/inputproto in DEPEND for some long
>> forgotten reason, for instance.
>>
>> The second option is much simpler and less error prone, but removes
>> the ability to depclean the proto packages.
>>
>> It seems that some sort of DEPEND variable that means "I only need
>> this when other packages are building against me" would be useful.
>> Thoughts?
>>
>> Matt
> 
> Another similar situation:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=342393

Maybe the virtual/mesa-build approach that I suggested can be adapted to
other similar situations:

  https://bugs.gentoo.org/show_bug.cgi?id=342393#c23

-- 
Thanks,
Zac

Re: [gentoo-dev] Re: How to handle dependencies on protocol headers?

[Alexander Bersenev]

I like a DEPEND way. But in this way many packages will need to be modified and missing dependencies likely appear. I developed an util to detect missing dependencies
https://bugs.gentoo.org/show_bug.cgi?id=autodep

Best,
Alexander Bersenev

On 16.09.2011, at 10:49, Zac Medico <zmedico@gentoo.org> wrote:

> On 09/15/2011 09:42 PM, Matt Turner wrote:
>> On Fri, Sep 16, 2011 at 12:32 AM, Matt Turner <mattst88@gentoo.org> wrote:
>>> Often packages depending on X11 libraries will also have to specify
>>> the X11 libraries' proto packages in DEPEND. This is because the X11
>>> library itself #includes files provided by the proto package. It's not
>>> really that the X11 library depends on this at run-time, so the
>>> protocol packages aren't specified in the RDEPEND of the libraries.
>>> 
>>> This is documented in a number of bug reports (see 379545), and it
>>> seems that the decision is between
>>> - add proto package to dependency list of packages using X11 libs
>>> - add proto package to rdepend list of the relevant library itself
>>> 
>>> The first is more correct, I think, but it's also much more annoying.
>>> Mesa winds up having x11-proto/inputproto in DEPEND for some long
>>> forgotten reason, for instance.
>>> 
>>> The second option is much simpler and less error prone, but removes
>>> the ability to depclean the proto packages.
>>> 
>>> It seems that some sort of DEPEND variable that means "I only need
>>> this when other packages are building against me" would be useful.
>>> Thoughts?
>>> 
>>> Matt
>> 
>> Another similar situation:
>> 
>> https://bugs.gentoo.org/show_bug.cgi?id=342393
> 
> Maybe the virtual/mesa-build approach that I suggested can be adapted to
> other similar situations:
> 
>  https://bugs.gentoo.org/show_bug.cgi?id=342393#c23
> 
> -- 
> Thanks,
> Zac
> 

Re: [gentoo-dev] Re: How to handle dependencies on protocol headers?

[Matt Turner]

On Fri, Sep 16, 2011 at 12:49 AM, Zac Medico <zmedico@gentoo.org> wrote:
> On 09/15/2011 09:42 PM, Matt Turner wrote:
>> On Fri, Sep 16, 2011 at 12:32 AM, Matt Turner <mattst88@gentoo.org> wrote:
>>> Often packages depending on X11 libraries will also have to specify
>>> the X11 libraries' proto packages in DEPEND. This is because the X11
>>> library itself #includes files provided by the proto package. It's not
>>> really that the X11 library depends on this at run-time, so the
>>> protocol packages aren't specified in the RDEPEND of the libraries.
>>>
>>> This is documented in a number of bug reports (see 379545), and it
>>> seems that the decision is between
>>>  - add proto package to dependency list of packages using X11 libs
>>>  - add proto package to rdepend list of the relevant library itself
>>>
>>> The first is more correct, I think, but it's also much more annoying.
>>> Mesa winds up having x11-proto/inputproto in DEPEND for some long
>>> forgotten reason, for instance.
>>>
>>> The second option is much simpler and less error prone, but removes
>>> the ability to depclean the proto packages.
>>>
>>> It seems that some sort of DEPEND variable that means "I only need
>>> this when other packages are building against me" would be useful.
>>> Thoughts?
>>>
>>> Matt
>>
>> Another similar situation:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=342393
>
> Maybe the virtual/mesa-build approach that I suggested can be adapted to
> other similar situations:
>
>  https://bugs.gentoo.org/show_bug.cgi?id=342393#c23

That would no doubt help the case of Mesa, but as can be seen by
http://tinderbox.dev.gentoo.org/misc/rindex/x11-proto/ , there are
lots of other cases as well.

Matt

Re: [gentoo-dev] How to handle dependencies on protocol headers?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

On Fri, 16 Sep 2011 00:32:49 -0400
Matt Turner <mattst88@gentoo.org> wrote:
> Often packages depending on X11 libraries will also have to specify
> the X11 libraries' proto packages in DEPEND. This is because the X11
> library itself #includes files provided by the proto package. It's not
> really that the X11 library depends on this at run-time, so the
> protocol packages aren't specified in the RDEPEND of the libraries.

This is a build-against dependency, and it's best expressed either by
its own BADEPEND, or (because it's apparently now possible, and because
otherwise we'd end up with six or seven *DEPEND variables) by switching
to something like DEPENDENCIES with a build-against label.

If the Portage guys aren't winding us up when they say that they could
handle something like DEPENDENCIES without major code changes these
days, then it could be on the cards for EAPI 5.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] How to handle dependencies on protocol headers?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Fri, 16 Sep 2011 07:25:29 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Fri, 16 Sep 2011 00:32:49 -0400
> Matt Turner <mattst88@gentoo.org> wrote:
> > Often packages depending on X11 libraries will also have to specify
> > the X11 libraries' proto packages in DEPEND. This is because the X11
> > library itself #includes files provided by the proto package. It's
> > not really that the X11 library depends on this at run-time, so the
> > protocol packages aren't specified in the RDEPEND of the libraries.
> 
> This is a build-against dependency, and it's best expressed either by
> its own BADEPEND, or (because it's apparently now possible, and
> because otherwise we'd end up with six or seven *DEPEND variables) by
> switching to something like DEPENDENCIES with a build-against label.

Please do not wreak exheres into Gentoo. The current variable forms are
complex enough; there is no reason to put even more logic into
the parser. And yes, it's better to have 7 *DEPEND variables than one
more magical, conditional thingie in the 'Dependencies' section.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] How to handle dependencies on protocol headers?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]

On Fri, 16 Sep 2011 09:54:47 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > This is a build-against dependency, and it's best expressed either
> > by its own BADEPEND, or (because it's apparently now possible, and
> > because otherwise we'd end up with six or seven *DEPEND variables)
> > by switching to something like DEPENDENCIES with a build-against
> > label.
> 
> Please do not wreak exheres into Gentoo. The current variable forms
> are complex enough; there is no reason to put even more logic into
> the parser. And yes, it's better to have 7 *DEPEND variables than one
> more magical, conditional thingie in the 'Dependencies' section.

From feedback so far, I think you're in the minority on that (at least
from people who have expressed an opinion), and that more people have
come out in favour of a single unified variable (not necessarily with
exactly the same syntax as exheres-0).

*shrug* I don't really mind about the syntax either way, and I suspect
that'll come down to a Council decision. I do care about getting the
exact definitions of what the various kinds of dependencies mean right
-- as you saw in the "what's available in pkg_setup?" discussion, we
have to be very very careful to avoid contradictions.

I think we need at least the following classes to represent all the
different dependencies people seem to need:

Build dependencies (DEPEND): available in src_*.

Run dependencies (RDEPEND): available when the package is used to
satisfy a dependency.

Install dependencies (IDEPEND?): available in pkg_setup. (Anyone
interested in why this is necessary should see the "Rephrasing *DEPEND"
thread on gentoo-pms. Sticking something in both DEPEND and RDEPEND
isn't enough, since RDEPEND-RDEPEND cycles are breakable. But please
read the original discussion before claiming we're wrong.)

Build-against dependencies (BDEPEND?): the thing described in the
original post in this thread.

Post dependencies (PDEPEND): available sometime.

Suggested dependencies (SDEPEND?): optionally available sometime.

We may also want:

Recommended dependencies (TDEPEND?): optionally available sometime,
and chosen unless the user says not to.

If we're trying to solve the SCM fetch problem in EAPI 5 (I don't think
we are):

Special Fetch dependencies (FDEPEND?): available during the special
fetch phase, however we decide to do that.

Note that suggested dependencies *have* to be PDEPEND-like. You can't
sensibly have suggested DEPENDs, since that violates the "repeatable
builds" principle. If something's an optional DEPEND, it needs a flag.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] How to handle dependencies on protocol headers?

[Brian Harring]

On Fri, Sep 16, 2011 at 09:08:36AM +0100, Ciaran McCreesh wrote:
> On Fri, 16 Sep 2011 09:54:47 +0200
> Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > This is a build-against dependency, and it's best expressed either
> > > by its own BADEPEND, or (because it's apparently now possible, and
> > > because otherwise we'd end up with six or seven *DEPEND variables)
> > > by switching to something like DEPENDENCIES with a build-against
> > > label.
> > 
> > Please do not wreak exheres into Gentoo. The current variable forms
> > are complex enough; there is no reason to put even more logic into
> > the parser. And yes, it's better to have 7 *DEPEND variables than one
> > more magical, conditional thingie in the 'Dependencies' section.
> 
> From feedback so far, I think you're in the minority on that (at least
> from people who have expressed an opinion), and that more people have
> come out in favour of a single unified variable (not necessarily with
> exactly the same syntax as exheres-0).

Personally... I think dependencies w/ labels is fricking ugly.  That 
said I understand the intent- being able to layer in multiple forms of 
deps (specifically new forms beyond what EAPI currently provides) 
which is good.

Strikes me, this is glep territory; write it up w/ the specifics so 
everyone can look at it (including literal examples), and work from 
there.  At the very least the facts would be on the table for people 
to read/vote on.

Same instant, the folks disagreeing can pick at the failings if any, 
and/or write up an alternative that uses seperated vars if they think 
it's friendlier.

Pretty much, I'd like to see this move into a realm of actual decision 
rather than just the current "use dependencies" "no they suck, and so 
do you".  Alternative suggestions for moving it in that direction are 
welcome, but the current bickering isn't really going anywhere (this 
particular discussion has been appearing since eapi1 or so).

Either way, we *do* need the new deps, so... getting something worked 
out would be preferable to having it keep dragging out.
~brian