Package: dpkg
Version: 1.14.4
Severity: wishlist
It would be nice if dpkg's status cache had a little more information;
say, enough so that other programs could recognize whether a package's
state had been changed.
The use case I'm interested in is aptitude. aptitude keeps various
pieces of information regarding a package, such as whether the user wants
to install it and the version they want to install. Ideally, this
information should go away if the package is modified by another program.
For instance, if I have told aptitude to remove a piece of software, but
then I remove it using dpkg, aptitude should forget that I wanted to
remove it. In fact, if I remove it using dpkg and immediately re-install
it with apt-get, aptitude should *still* not try to remove the package.
Right now, aptitude detects these cases by checking the dpkg status.
However, this has two major drawbacks:
(1) it can't detect sequences of changes that leave the package
in the same state that it started in, as the remove and re-install
example above.
(2) when dpkg performs actions on behalf of aptitude, it's necessary
to write back to aptitude's cache that the actions were performed.
If this isn't done (for instance, due to a user interrupt),
inconsistent behavior can result. (see #429388; it is a bug,
but the fix cannot be complete due to this problem)
By way of explaining (2), say aptitude was about to remove a package,
but the user interrupted it and removed it with dpkg. If the user then
reinstalls it with dpkg before running aptitude, aptitude will go ahead
and remove the program again, because it doesn't know that the program's
state has changed.
I believe that it would be a huge benefit if dpkg could store a unique
token that indicates the current "version" of a package's information.
For instance,
Package: foo
State: install ok installed
Status-Key: 9d43acb2112f084a
...
Any dpkg action performed on foo should modify the status-version. The
choice of a 16-digit hex value was arbitrary; as a user I don't care what
you use, but I figured a hex key is the most likely thing to put there.
Does this sound at all useful to anyone else? It seems likely to me
that other applications would benefit (I hope so, cause I'd really like
to finally wipe out these bugs), but I can't think of any obvious
beneficiaries at the moment.
Daniel
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-xen-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg depends on:
ii coreutils 5.97-5.3 The GNU core utilities
ii libc6 2.5-11 GNU C Library: Shared libraries
dpkg recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
