Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Michał Górny <mgorny@g.o>
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: How to handle dependencies on protocol headers?
Date: Fri, 16 Sep 2011 09:08:36 +0100
On Fri, 16 Sep 2011 09:54:47 +0200
Michał Górny <mgorny@g.o> 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:
signature.asc (PGP signature)
Replies:
Re: How to handle dependencies on protocol headers?
-- Brian Harring
References:
Re: How to handle dependencies on protocol headers?
-- Ciaran McCreesh
Re: How to handle dependencies on protocol headers?
-- Michał Górny
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: How to handle dependencies on protocol headers?
Next by thread:
Re: How to handle dependencies on protocol headers?
Previous by date:
Re: x32 fun pants
Next by date:
Re: x32 fun pants


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.