On 2008-07-15 22:58, Tiziano Müller uttered these thoughts:
> Patrick Börjesson wrote:
> > On 2008-07-15 21:40, Tiziano Müller uttered these thoughts:
> > The same thing would apply to gcc if all "real" depends were to be
> > required in all ebuilds, but that would pretty much have to be manually
> > stated since the PM wouldn't be able to judge that by automatic
> > measures. 
> That's a different thing:
> A dependency on gcc just ensures that gcc is installed not that it is
> actually used to build a package.

Not quite sure what you mean here. I'm just saying that if you want to
go the route of stating all deps explicitly, you have to state in the
ebuild (DEPENDS) that gcc is needed to build the package, if that's the
case. I'm not against this at all (I'm not an ebuild-maintainer), i just
gave an example for when there's no sane way for the PM to automatically
inject a dependency. 

> And for such a dependency we'd need new ways to express deps since gcc is
> only needed when building packages not when it gets installed from a
> binpkg.

Portage (or whichever PM you want) uses it's own way of packaging
binpkgs, so for it to be able to extract those binpkgs, a RDEPEND on the
applications used for that specific task has to be stated in the _PM_
itself. It isn't the ebuild deciding which format it's gonna be
packaged down into. 
I'm far from sure about this, but DEPENDS aren't really taken into
consideration when installing from a binpkg, so stating (f.ex) gcc in
DEPENDS wouldn't draw it in when you install the package from a binpkg. 

It is however known to the ebuild-maintainer and/or the PM which format 
the source is packaged in, so that's a sane thing to put in DEPEND,
whether by manual editing of the ebuild/eclass, or by automation in the PM. 

Patrick B

-- 
()  The ASCII Ribbon Campaign - against HTML Email
/\  and proprietary formats.