I like the way e.g. ArchLinux' yaourt (or if you're not that lazy, abs+makepkg; and from what I read so far, Gentoo's ebuild as well) automatically take care of obtaining, compiling and installing dependencies (and their dependencies etc.) before compiling a desired package. Currently I'm working with a system that does not natively provide such a mechanism (a Buffalo LinkStation Pro Duo with root access via ssh) and need to compile some programs with horribly complex dependency chains, crawling through which manually is really tedious, so I'm wondering if there either is

  • a tool similar to the aforementioned ones, which basically takes a sourcecode directory (or .tar.gz or git-repo or ...) and before compiling checks for missing dependencies, more or less automatically obtains their sourecode (recursing until all dependencies are resolved)
  • a way to configure one of these tools such that they respect deviations from their own distribution, e.g. installing everything under /opt and not attempting to upgrade the (firmware-specific) kernel?

Sure enough there are many peculiarities in the general case, but for the sake of it assume 90% of all dependencies merely require a ./configure --prefix=/opt && make && make install run.

  • Such tools always have to be distribution specific or will not work as well as they should. – Bananguin Oct 29 '13 at 8:40
  • There might be some tuning required, but assuming all I'd manually have to do after locating the source would be ./configure --prefix=/opt && make && make install in most cases, this should be quite automate-able – Tobias Kienzler Oct 29 '13 at 8:44
  • Maybe interesting approach/inspiration: Rootless GoboLinux and its recipe system – Tobias Kienzler Oct 29 '13 at 9:24
  • Have you considered debootstrap-ping a Debian derived distribution in there and use it over chroot (or LXC if the buffalo kernel has it enabled)? – Stéphane Chazelas Oct 29 '13 at 10:32
  • The problem is, that there is not always just one package to provide a certain file or library. How should a build system know which piece of software to install? Thats a desicion that does not follow simple dependency tracking. Thats why it has to be distribution specific. – Bananguin Oct 29 '13 at 10:46

i don't think such a thing is really feasible, so the short answer would be:


the examples you mentioned are really tailored to build everything from scratch, hence you have a workflow that allows to do just that (build everything, including dependencies).

other distributions (like Debian and all it's derivatives) are focused more on downloading pre-compiled binaries (rather than building locally them from scratch), so they do not offer a framework to autocompile just the dependencies.


as far as simply resolving dependencies for a given package, this is one of the main tasks the distribution maintainers are facing: find out which packages require which (versions of) libraries,...

since distributions put heavy human power into this task, i doubt whether it is automatable.

| improve this answer | |
  • I doubt this is the answer - in many cases ./configure --prefix=/opt && make && make install works perfectly fine once all dependencies are resolved – Tobias Kienzler Oct 29 '13 at 9:11
  • @TobiasKienzler your answer is specifically about "automatically compile+install dependencies" of a given package; any call to ./configure does not resolve any dependencies; it will simply compile+install the package itself (given all deps are resolved), which is really not what you asked. apart from that, not all packages use autotools. – umläute Oct 29 '13 at 9:16
  • what I meant was the major difficulty in most cases lies in parsing configure's error messages on missing dependencies and finding/downloading their source, and not necessarily in compiling/installing them (though if they're not using autotools some metainformation à la ebuild or GoboLinux recipes needs to be obtained) – Tobias Kienzler Oct 29 '13 at 9:22
  • 3
    @TobiasKienzler the problem is, that in many (if not most) cases, the error-messages on missing dependencies are user-defined rather than standardized (thus hard to parse automatically); also some dependencies are soft (that is: the package will compile with missing features) but these may be hard dependencies for you (e.g. without those features the package is worthless for you). – umläute Oct 29 '13 at 9:48
  • Good point, though obviously it is silly to re-resolve dependencies that other distributions' maintainers already did resolve - their resolution is potentially easier to adapt than stating from scratch – Tobias Kienzler Oct 29 '13 at 9:59

Contrary to the other answer, such tools exist, though I haven't decided on one yet:

While they include distributing precompiled binaries, they also allow for compilation.

Also cf. the question Non-Root Package Managers

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.