Finding dependencies for new receipts

[Harald Klimach <klimach@xxxxxxx>]

Hi,

> Going forward, we could use a sat-solver (similar to libzypp in OpenSuse)
> for dependency resolution in package management. Tazpkg could be enhanced to
> use a sat-solver backend.
> A nice (old) write-up on the justification for a solver based package
> management is:  http://www.mancoosi.org/edos/manager.html
> 
> Its should make for quite a robust package management system, with automatic
> resolution of dependencies and clean failure in cases where they cant be
> resolved.
My point was not regarding the dependency resolution. The issue at hand is rather,
that there are some dependencies missing in the receipts description. For the
author of the receipt it is however not easy to keep track of all necessary
dependencies, that are needed for each package, as his working machine may already
have them installed, so he doesn't run into issues when compiling the code.

> > I've had a similar experience with dependencies as Harald, so I pass along
> > my notes....
Thanks a lot for the cleanup and lists.

> > In short, I think we've both seen pretty much the same thing....
> >
> > I've thought about a means for dependency testing, too, and one I idea that
> > I had was using a virtual machine and keeping a "clean" environment as a
> > saved state.  I haven't had the best performance running SliTaz in a VM,
> > though if CONFIG_NO_HZ were enabled in the kernel configuration, that would
> > greatly improve the performance of SliTaz in a VM.
I think using a virtual machine is a little bit over the top. Propably there
could be something done using chroot environments to tackle this problem.
In GoboLinux a chrootCompile script is used:
http://gobolinux.org/?page=chrootcompile (currently down)

Citation: "
   1. it allows you to build packages using different tools than you currently have installed in your live system;
   2. it protects your system from any problems during any step of the compilation process;
   3. and it helps you ensure that the dependency information of your recipe is correct.

When you run a recipe through ChrootCompile, it will read its dependency tree, and based on that, it will construct a directory containing a minimal, yet fully-working GoboLinux system, containing the basic packages required by the Compile toolchain (such as a shell, a compiler and basic Unix commands) and the dependencies listed by your recipe -- nothing else. Then, it will run your recipe through Compile in this isolated system, producing, if everything goes well, a binary package by the end of the process.

This way, you can build packages using, for example, different versions of GCC and Glibc than your system uses. In its default configuration, ChrootCompile fetches the basic set of packages of its toolchain from a fixed repository; ensuring that the basic ABI of packages built with it remains consistent. This step is performed by a separate script, SetupChrootEnv. 
" Citation

See also http://gobo.kundor.org/wiki/Compile (I think the chroot functionality was moved into the
Compile script itself in the meantime).

This is a really nice feature, and helps a lot to find all required dependencies for a given package.


cheers,
Harald

---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/