On Wed, May 26, 1999 at 01:46:41PM +0200, Sven LUTHER wrote:
> > > So, what's the problem? We don't autodetect all of binary dependencies
> > > either. Maintainers generally know what they need to build their packages;
> > > it should be trivial for them to list the dependencies explicitly!
> > >
> > > Besides, if source dependencies were completely autodetectable, we wouldn't
> > > need them.
> > Agreed. We don't need any magic, just a common location for that useful
> > piece of information.
> I didn't follow all of this thread, but i think source dependencies are mostly
> usefull for people recompiling the package.
> So it would be nice to have a some kind of wrapper library that patches the
> open and such function from glibc, and log the accessed files (the one that are
> not in the build directory naturally) after that you just have to run some kind
> of dpkg -S on these files, and you get all packages needed for building this
> you would need something a bit like what fakeroot does for it, so it is not
> The dpkg -S part would be quite slow i think, and produce a very big number of
> packages, but you could reduce them by providing a standard debian compiler
> metapackage (or whatever it is named this days) including stuff like make and
> gcc. or maybe various of them for lets say perl-devel, gcc-devel, text-only,
> etc, ...
Of course, these are all very nice ideas... but we currently don't
have any PLACE to put the list (where it'll get used by dpkg* tools),
whether it is manually or automatically generated!
IIRC Ben Collins had made a functional patch to dpkg package about
this a few months ago, though it wasn't very featurful it did the
job (dpkg-source would check the list, and warn if you don't have
a listed package installed).
enJoy -*/\*- http://jagor.srce.hr/~jrodin/