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 > package. > > you would need something a bit like what fakeroot does for it, so it is not > impossible. > > 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/
