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