On Friday 19 June 2009 07:14:08 Bernhard R. Link wrote:
> Actually, I'm quite open to having some depedency handling in reprepro
That is interesting. I've been working on the assumption that there would
never be any dependency handling in reprepro, as I didn't consider it part of
it's function.
> and already have written some simple prototype for a related project.
> The problem is that calculating a simple cover of selected packages in
> the dependency graph is not enough:
>
> Usually the cover is not unique but the existance of alternatives in
> dependencies causes multiple solutions.
This is a problem across the board. Even aptitude seems to have problems in
automatically determining the most appropriate dependencies.
Let's use this example. Suppose you already have a system with apache2
installed, but no php yet. Next you try to install phpldapadmin, using
aptitude (from the command line). Aptitude will tell you that
libapache-mod-php5 is broken, and proceed to present some alternatives that
would resolve the dependencies.
--------------------------------------------------------------------
umeboshi@stdinstall:~$ sudo aptitude -s install phpldapadmin
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
The following packages are BROKEN:
libapache-mod-php5
The following NEW packages will be installed:
php5-common{a} php5-ldap{a} phpldapadmin
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 3821kB of archives. After unpacking 11.8MB will be used.
The following packages have unmet dependencies:
libapache-mod-php5: Depends: libdb4.4 which is a virtual package.
Depends: apache-common (>= 1.3.34) which is a virtual
package.
Depends: php5-common (= 5.2.0-10+lenny1) but
5.2.6.dfsg.1-1+lenny3 is to be installed.
The following actions will resolve these dependencies:
Install the following packages:
libapache2-mod-php5 [5.2.6.dfsg.1-1+lenny3 (stable)]
Keep the following packages at their current version:
libapache-mod-php5 [Not Installed]
Score is 50
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Install the following packages:
php5-cgi [5.2.6.dfsg.1-1+lenny3 (stable)]
Keep the following packages at their current version:
libapache-mod-php5 [Not Installed]
Score is 50
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Install the following packages:
libapache2-mod-php5 [5.2.6.dfsg.1-1+lenny2 (stable)]
php5-common [5.2.6.dfsg.1-1+lenny2 (stable)]
php5-ldap [5.2.6.dfsg.1-1+lenny2 (stable)]
Keep the following packages at their current version:
libapache-mod-php5 [Not Installed]
Score is -30
--------------------------------------------------------------------
etc, etc, etc .....
apt-get, on the other hand, seems to use the first dependency that's listed as
an alternative.
Depends: apache2 | httpd, php5-ldap, libapache2-mod-php5 |
libapache-mod-php5 |
php5-cgi | php5, debconf (>= 0.5) | debconf-2.0
Here, since we already have apache2 on the system, libapache2-mod-php5 is
chosen (I'm guessing because it's the first one listed).
> For an initial checkout that
> is no problem, as one can choose one some set by some pseudo-random
> selection (like "packages with alphabetically lower names get the
> first depedency in an alternative tried first" and similar things
> for virtual packages).
I think that it should be up to the maintainer of the local mirror to
explicitly list the alternatives that are preferred. I don't think that
there is anyway that an automatic dependency resolver will ever be able to do
this. The automatic dependency resolver can make this easier by marking
those dependencies as "automatically selected, alternative available" or
something similar. One of the nice things about germinate, is that it has
a "why" column in it's output that tells why a package was selected (although
it doesn't make it clear that it's one of many alternatives).
> The problem is that no such criterion can be
> stable against changes in the partially mirrored distribution.
I'm not sure what you mean here. Are you talking about an alternative that's
selected for the local mirror, but removed from the official mirror?
>
> So in this cases knowing what packages upstream has and what packages
> are wanted is not enough but one has to take into account what packages
> are currently selected. And a simply covering no longer is enough but
> one needs a full resolver knowing which installed states can be easily
> brought to which other installed states. (and things get even more
> complicated if the currently mirrored packages allow multiple subsets
> which clients using this repository might have installed)...
>
I used to have to keep outdated libraries in my filter list when I was using a
partial sid mirror, as some packages would become uninstallable without them.
I've learned over the course of years that you can't run from a snapshot of
sid, but rather have to use it for a few months to get the dependencies to
work out, even though many of those dependencies have changed versions in the
official repository.
But really, that last paragraph is me trying to understand what you were
saying. You went a bit above my head, and I'm having trouble following you.
> Hochachtungsvoll,
> Bernhard R. Link
--
Thanks:
Joseph Rawson
Attachment:
signature.asc
Description: This is a digitally signed message part.