2

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.

Improve this question
5
  • Such tools always have to be distribution specific or will not work as well as they should.
    – Bananguin
    Commented Oct 29, 2013 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
    Commented Oct 29, 2013 at 8:44
  • Maybe interesting approach/inspiration: Rootless GoboLinux and its recipe system
    – Tobias Kienzler
    Commented Oct 29, 2013 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
    Commented Oct 29, 2013 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
    Commented Oct 29, 2013 at 10:46

2 Answers 2

Reset to default
1

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

no

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.

update

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
9
  • 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
    Commented Oct 29, 2013 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
    Commented Oct 29, 2013 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
    Commented Oct 29, 2013 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
    Commented Oct 29, 2013 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
    Commented Oct 29, 2013 at 9:59
0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .