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 |