The new release of dose, apart from a few bug fixes, ships a new and improved version of dose-builddebcheck (man page). All the improvements done to dose-builddebcheck are from a set of patches submitted by Johannes Schauer in the context of the Bootstrap GSoC. We are still actively working on this. I invite you to read josh’s recent blog post on the topic. For more background and discussion, you can have a look at the archives of this mailing list.

Dose-builddebcheck (or buildcheck for short) is similar in intent to dose-debcheck but for source packages. Buildcheck allows you to check, just by looking at the Source and Packages files, if all the dependencies can be satisfied and installed, all this in a matter of seconds (less then 30 secs to test all the source packages in sid on my laptop).

A simple example :

deb-buildcheck.native \
  --deb-native-arch=amd64 \
  tests/DebianPackages/Sid-amd64-Packages-050812.bz2 
  tests/DebianPackages/Sid-Sources-050812.bz2

native-architecture: amd64
background-packages: 55945
foreground-packages: 18175
broken-packages: 64

real    0m22.223s
user    0m21.937s
sys 0m0.204s

This will check for all source packages in the Source file if their build dependencies can satisfied on amd64 given the Packages binary file. This is nice but nothing new. A script based on the old edos tools has been around for quite a long time. We want more !

The new exciting feature brought by Johannes is the capability of checking source packages for cross-compilation :

dose-builddebcheck -f -e -s --checkonly picolisp \
  --deb-native-arch=amd64 \
  --deb-foreign-archs=armel \
  --deb-host-arch=armel \
  tests/DebianPackages/Sid-amd64-Packages-050812.bz2 \
  tests/DebianPackages/Sid-armel-Packages-050812.bz2 \
  tests/DebianPackages/Sid-Sources-050812.bz2 

(I)Sources: Parsing Sources file tests/DebianPackages/Sid-Sources-single-version-050812.bz2...
(I)Format822: total packages 17723
(I)Format822: Merging repositories
(I)Packages: Parsing Packages file tests/DebianPackages/Sid-armel-Packages-050812.bz2...
(I)Packages: Parsing Packages file tests/DebianPackages/Sid-amd64-Packages-050812.bz2...
(I)Format822: total packages 58095

native-architecture: amd64
foreign-architecture: armel
host-architecture: armel
report:
 -
  package: src:apicolisp
  version: 3.1.0.7-1
  architecture: kopensolaris-amd64,solaris-amd64,amd64,any-i386,any-armel,any-armeb,any-arm,any-avr32,any-hppa,any-m32r,any-m68k,any-mips,any-mipsel,any-powerpc,any-s390,any-sh3,any-sh3eb,any-sh4,any-sh4eb,any-sparc,any-armhf
  source: picolisp (= 3.1.0.7-1)
  status: ok

background-packages: 75818
foreground-packages: 17723
broken-packages: 0

This will check, if the source package ‘picolisp’ in the Sources file can be cross compiled for ‘armel’ on the native architecture ‘amd64’ given the list of binary packages in the Packages file. The generated report is, as for dose-debcheck, encoded in yaml and it can be simply parsed using an off-the-shelf library.

Apt is the canonical tool that can be used to check if a package can be cross compiled. Josh found a few discrepancies between dose and apt results. This was a very good test for both tools: Bug #683786 is a very interesting read…

Dose 3.1.1 (the latest release) should land soon in experimental. Otherwise you can get it from our (new) project homepage.

Recently we did a bit of clean up of our git repositories and now thanks to roberto’s efforts we have a new shiny git repository on the inria forge and two mailing lists to discuss development and user questions.

If you are a user, or interested in dose development, please sign up to these mailing lists:

• dose-discus :http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/dose-discuss
• dose-devel : http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/dose-devel

if you already have a copy of the latest git repository, you can change the upstream repository issuing the following command :

     git config remote.origin.url git://gforge.inria.fr/dose/dose.git

If you are curious, you can clone dose git clone git://gforge.inria.fr/dose/dose.git and let us know what you think about it.

The API documentation is available here. The man pages or various applications developed on top of the dose library are available here. We are still actively working on the documentation and any contribution is very much welcome. I’m working on a nice homepage…

You can get the latest tar ball release here : https://gforge.inria.fr/frs/?group_id=4395 Old releases will be left on the old forge.

Update

And now we are even social ! follow us on identi.ca : http://identi.ca/group/dose3

Last year we invited David to work with us for a few days to add a generic interface to apt to call external solvers. After a few iterations, this patch finally landed in master and recently (about 3 months ago), in debian unstable.

[ David Kalnischkies ] * [ABI-Break] Implement EDSP in libapt-pkg so that all front-ends which use the internal resolver can now be used also with external ones as the usage is hidden in between the old API * provide two edsp solvers in apt-utils: - ‘dump’ to quickly output a complete scenario and - ‘apt’ to use the internal as an external resolver

Today the new version of apt-cudf was upload in unstable and with it the latest bug fixes that makes it ready for daily use. I’ve used it quite a lot myself to upgrade my machine and it seems working pretty well so far… The most important difference with the old version is the support for multi-arch enabled machines.

This marks an important milestone in our efforts to integrate external solvers, built using different technologies, directly into apt. From a user prospective, this means that (s)he will have the possibility to check if there exists a better (best ?) solution to an installation problem then what proposed by the internal apt solver. Moreover, even if apt-get gives very satisfactory answers, there are occasions where it fails miserably, leaving the user wondering how to unravel the complex web of dependencies to accomplish his task. Available cudf solvers in debian are at the moment : aspcud, mccs and packup.

From an architectural point of view this is accomplished by abstracting the installation problem via a simple textual protocol (EDSP) and using an external tool to do the heavy duty translation. Since all solvers now available in debian are not meant to be debian-specific, using them involve a two step translation. The EDSP protocol specification is for the moment “hidden” in the apt documentation. I hope to find a better place for it soon : it would be cool if other package managers as smart or cupt could add an implementation on EDSP in their code so to automatically benefit of this technology.

To make it happen, Apt first creates an EDSP file that is then handled to apt-cudf that takes care of the translation to cudf and back into EDSP that is then read back by apt. Apt-cudf is the bridge between edsp and the external solvers and takes care of doing the book keeping and to select the right optimization criteria.

Roberto recently wrote a very nice article explaining how to use apt-get with an external solver.

In a nutshell, if you want to try this out you just need to install apt-cudf, one external solver like aspcud from the university of Pasdam and then call apt-get using the —solver option (that is not yet documented #67442 ). For example :

apt-get install -s gnome --solver aspcud

This will install gnome while using the a optimization criteria that tries to minimizing the changes on the system. Various other optimization criteria for all apt-get default actions can be specified in the apt-cudf configuration file /etc/apt-cudf.conf

I hope the new release of apt-cudf make it into testing before the freeze. Time to test !!!

Finally the dose3 libraries and tools landed in testing this weekend. We solved a couple of bugs already and it seems nobody complained too loudly. If you used the edos tools in the past you might be interested to check out our new tools in the package dose-extra.

Actually @mancoosi we will be delighted to ear about you experience with our tools and how to make them better and more useful. Please drop me a line !

The next major release of dose will be multi-arch aware and provide performance improvements and other minor features.

If you missed it, and you are now curious, I delivered a talk at fosdem regarding our tools:

• QA tools for FOSS distributions (FOSDEM 2012) - Pietro Abate (video)

A big thanks to ralf of course for packaging everything !

Thanks to Ralf’s work, dose3 has been just accepted in debian experimental !!! yuppiiiii \o/

Dose3 is a framework made of several OCaml libraries for managing distribution packages and their dependencies.

Though not tied to any particular distribution, dose3 constitutes a pool of libraries which enable analyzing packages coming from various distributions.

Besides basic functionality for querying and setting package properties, dose3 also implements algorithms for solving more complex problems (monitoring package evolutions, correct and complete dependency resolution, repository-wide uninstallability checks).

For the ocaml affectionados the API of the library is available here (there is still a bit of work to do here…) . The source code shipped in each release does not include a vast range of applications sitting in the experimental directory. You can have a look at these in our svn.

if you want to get a copy of the development / bleeding edge / unstable version from svn, you can check it out from the svn

svn co https://gforge.info.ucl.ac.be/svn/mancoosi/trunk/dose3

user/pass : mancoosi/mancoosi