Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

On Fri, Jul 01, 2005 at 01:49:19PM -0400, 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 ?
Sort of, although I'd recommend a level of indirection.  See jason's 
metapkg glep, if the package requires a c toolchain,
BDEPEND="virtual/c-toolchain" which is a metapkg expanding out to 
binutils/gcc/etc.

Meanwhile, back to the "you want us to add what?", our dependency 
graph *is* incomplete.  Something like 600 ebuilds in the tree state a 
dependency on gcc- we have 19000 ebuilds.  Not all requires gcc to 
build, but I'd bet it's a tad bit more then 600.
Full dependency information hasn't be viable due to resolver issues, 
which will be fixed.

Regarding the "require whatever is used to uncompress the source", 
hadn't thought about it, but that _should_ be specified imo.  That's 
also being a bit anal, but frankly, if the resolver can handle it, why 
shouldn't we specify the full deps?

Grouping/indirection obviously should be employed to mke the task 
easier, but the point stands.

To head off the "profile has it, so we don't need it", consider a 
user profile, literally, a user desktop profile.  Kde, gnome, office 
crap, etc.  Right now, for such a profile you would need the toolchain 
tagged in, which I posit is invalid.

Give portage the data it needs, and it can map out what it needs to 
build up to the system definition.

For the user profile example, if the user doesn't need it, why 
shouldn't an emerge depclean cleanse the tools that were merged to 
build packages?
~harring