Re: RFC interaction with external dependency solver: "APT" state
2010/5/19 Stefano Zacchiroli <zack@debian.org>:
> I see a solution that still preserves the "one pass" approach, not
> adding any need of and ping-pong between package manager and solver. The
> idea is that in the answer from the solver, you get package stanzas as
> follows:
>
> package: foo
> version: 1.2.3-4
> id: adgf31452135hkashdfa
> installed: yes
So let us assume the user has installed <awesome,1,Packages-1>.
In the next request, which id will <awesome,1,Packages-1> have
compared to <awesome,1,status-file>?
Are these versions merged or not?
If they are merged we have multiple origins (Packages-1, status)
and converter and manager could possibly disagree on the merge
[if i understand the last thread correctly cupt could also choose to
merge (Packages-2, status) - and $manager might want to merge
(Packages-{1,2},status) for simplicity].
If not we have for all installed packages an installed version and a
online available version (which will be most of the time the same,
but not always - e.g. binary rebuilt without version number change)
and a solver chooses either the one or the other version - and the
manager later needs to choose if he will "install" this or another
version -- if he chose to merge the versions he will do nothing,
which could result in a broken system in the (status,Packages-2)
case (remember: the dependencies were different) -
We can argue now that it is a bug to merge these versions,
but i guess you will earn a "wont-fix" for reporting it as it is a
design decision to allow crap situations like this or not…
(and while i don't agree i at least understand it)
I am sure we can all find more "nice" cases for either of these variants.
> The idea is that "id" is an optional property (defaulting to "") and
> that the triple <package, version, id> uniquely identify a package for
> APT; i.e.: it will be able to discriminate among multi-arch,
> locally-rebuilt packages, and packages coming from different APT lists.
Just to be sure, we still talk about all package managers in this
thread here - or is it really about APT alone? I tried to be relatively
generic until now… - you later say "friends", this could mean
rev-depends like aptitude and co. - but also smart/apt2/cupt/…
I at least hope we are not deadly enemies, but friends… ;)
Also, i don't see why multi-arch is in the same list as locally-rebuilt
packages. The are completely different problems:
A locally rebuilt version 1 will always satisfy a depends on version 1.
A version from another architecture may or may not do this.
MultiArch can be modeled with <name,arch> and some dependencies
(at least my implementation chooses to do this so the packages from
different archs can be handled as complete different packages by the
internal apt resolver resulting in nearly zero changes to the resolver until
now, see also README.MultiArch).
> The point is now obviously which kind of 'id' should be used to ease
> interaction with APT and friends. I see at least the following
> possibilities, no idea what would be the most preferable:
>
> 1) id is the sha1/md5/... of the file the package comes from
> 2) id is the argc (on the cmdline) of the file the package comes from
> 3) id is the path of the file the package comes from
>
> The advantage of (1) is that APT (I guess) already has some checksum of
> packages list out of the APT-secure stuff, no idea whether they are
> easily associable to individual packages though. Also, I don't know
> whether some checksum of /var/lib/dpkg/status is available already or
> not.
While the Packages files have checksums of the deb files the status file
has not. As i said already APT tries to "fix" this by hashing installsize and
the list of dependencies, so a version in APT is <numberstring, hashvalue>
full info e.g. in #574956 and #574072 in which you can also see what
happens if two version merger disagree (in this case human brain vs. APT)
as well as this situations are not completely academic…
Best regards,
David Kalnischkies
Reply to: