Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Date: Tue, 22 Apr 2008 18:40:05
Message-Id: 1208889095.7206.18.camel@cgianelloni.quova.com
In Reply to: Re: [gentoo-dev] Dependencies that're available at pkg_*inst by Ciaran McCreesh
1 On Tue, 2008-04-22 at 08:09 +0100, Ciaran McCreesh wrote:
2 > > We definitely don't want to install DEPEND at the pkg_* stages, so I'd
3 > > say the requirement there, if you're asking, is prior to src_*, if
4 > > that matters.
5 >
6 > If the alternatives are not being able to install from a binary at all
7 > due to circular dependencies, or being able to install from a binary
8 > using DEPEND to satisfy circular dependencies, which would you take?
9
10 Given the trouble that we have every release with trying to cram
11 everything our users want into a limited space, I'd rather the damned
12 thing not install than pull in a bunch of packages we don't need, just
13 to satisfy a dependency that isn't even used during execution of the
14 package.
15
16 > > I'd love to have some kind of functionality to allow some kind of
17 > > "optional" dependencies. The only real way that I could see this
18 > > working is if we tracked what was installed as an optional dependency,
19 > > and not reinstall it if it has been removed the next time the
20 > > depending package is merged.
21 >
22 > Sort of like what kdebuild has for suggested dependencies, but less
23 > strong?
24
25 Pretty much, yeah. The main difference that I would see from the
26 current *DEPEND variables, besides what was said above, would be that a
27 lack of visibility wouldn't stop the package merge. If sys-apps/foo had
28 ODEPEND="dev-libs/bar" and dev-libs/bar was masked, it simply wouldn't
29 be installed.
30
31 --
32 Chris Gianelloni
33 Release Engineering Strategic Lead
34 Games Developer
35 --
36 gentoo-dev@l.g.o mailing list