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.

Tobias Kienzler
  • 9,374
  • Such tools always have to be distribution specific or will not work as well as they should. – Bananguin Oct 29 '13 at 08: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 08:44
  • Maybe interesting approach/inspiration: Rootless GoboLinux and its recipe system – Tobias Kienzler Oct 29 '13 at 09: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

2 Answers2

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.

umläute
  • 6,472
  • 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 09: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 09: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 09: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 09: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 09:59
  • @TobiasKienzler also consider that the messages rarely provide you with the URL where you can download the source of the missing dependency, they just say "Error: missing library.X.soor whatever. You then need to figure out what program provides that and go look for where to download it. Since these are not standardized, I doubt you can automate. The dependencies are explicitly listed by package name in arch packages, that's whyyaourt` can do it. – terdon Oct 29 '13 at 15:01
  • @terdon That's precisely what my question is about - a tool that, without being too distribution-specific, knows dependencies and where to obtain the dependency sources. That alone would save me a lot of work, and if it outputs a suggested compilation order / checklist I could still manually compile but no longer needed to hunt down libWhatMe's source – Tobias Kienzler Oct 29 '13 at 15:17
  • @TobiasKienzler I know but I don't see how that could be possible without a centralized source repository with a specified format. If you just have the dev's configure script, you have no idea what error message he/she will choose to print so you can't automate parsing them. That's one of the main points of using distributions, they do that for you. Think about it, libWhatMe could be found at libewhatme.com or sourceforge/libwhatme or libwhatme.org or libcompletelydifferent.com or wherever, you can't know because there is no standard for this. – terdon Oct 29 '13 at 15:26
  • @terdon Indeed, but my point is there could (theoretically) be a tool which has that lookup integrated (or on a centralized server) - and that is something which could be independent of a distribution which then adds some patches to use the respective paths etc. – Tobias Kienzler Oct 29 '13 at 15:35
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

Community
  • 1
Tobias Kienzler
  • 9,374