1 |
On Saturday 02 July 2005 02:49, Mike Frysinger wrote: |
2 |
> On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote: |
3 |
> > Currently, we pretty much leave out the big dogs of build depends from |
4 |
> > ebuilds- basically we rely on the profile to require a suitable |
5 |
> > toolchain. Couple of issues with this though- |
6 |
> > |
7 |
> > 1) Deps aren't complete for an ebuild. |
8 |
> > 2) Merging a php or python lib that doesn't require compilation |
9 |
> > doesn't require a full toolchain, distutils/pear or make mainly. |
10 |
> > So autoassuming a c/c++ toolchain is required isn't accurate. |
11 |
> > 3) For automatically handling x-compile deps, without this info bound |
12 |
> > to an ebuild, portage will _never_ be able to know what |
13 |
> > dependencies are x-compile targets, and what deps must be natively |
14 |
> > merged. |
15 |
> |
16 |
> so what you're proposing is that we add binutils/gcc/glibc to every package |
17 |
> that compiles something, make to every package that uses make, |
18 |
> sed/grep/bash/coreutils to every package which runs configure, and |
19 |
> tar/gzip/bzip2 to every package which has a gzipped/bzipped tarball in |
20 |
> SRC_URI ? |
21 |
|
22 |
I'd agree with this as far as the compiling only. For the rest, they should |
23 |
really be RDEPENDs from portage (or whatever it is that provides econf, emake |
24 |
and unpack) itself. econf, emake and unpack are parts of the "ebuild |
25 |
environment" that every ebuild is guaranteed to have available. |
26 |
|
27 |
However, if an ebuild chooses to run make directly for some unknown reason or |
28 |
use some specific tool to unpack an unsupported file format, the package |
29 |
should really be explicit about its dependency. |
30 |
|
31 |
Regards, |
32 |
Jason Stubbs |
33 |
-- |
34 |
gentoo-dev@g.o mailing list |