Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

[quoting out of order for convenience]

Guillem Jover wrote:

> I've not checked but I'd
> expect this would imply only few lines of code on the apt side, just
> removing the just disappeared package from the to be configured queue.

>From my reading of pkgDPkgPM::ProcessDpkgStatusLine, APT does not
care much about statusfd.  It is treated as just some information
about progress to pass to the end-user.

Strangely enough, helping the end-user in this way involves
remembering the state of each package being operated on.  When all is
going to plan, APT can report that a package is

 half-installed --- Preparing foo
 unpacked --- Unpacking foo
 unpacked --- Preparing to configure foo
 half-configured --- Configuring foo
 installed --- Installed foo

And there is a map from package names to integers indicating where in
such a sequence each particular package is.

Currently, this map does not affect APT’s order of operations.
Instead, the list of operations is planned in advance and followed
rigidly, regardless of the situation in the field.

APT experts: would it make sense to build in additional intelligence
of this kind?  In other words, would it be safe and worthwhile to
teach pkgDPkgPM::Go() to use the PackageOps map to skip a request to
configure a package if it has disappeared?

> There's more to the installation/removal process than just
> the metadata, there's the maintainer scripts which can fail at any
> point, there's file conflicts, there's triggers, etc.

AFAIK both APT’s and cupt’s approach is rather to hope everything goes
according to plan and either do as much as possible or stop at the
first error.

A high-level package manager that collaborates with the user to deal
appropriately with problems as they come might be a lovely thing.
apt-get uses a simpler approach: to fix problems, you run it again.

One final thought.

dpkg itself does not use the kind of intelligence you are talking
about to handle disappearing packages.  It simply assumes that during
an --install run, any package it is trying to configure that is not
installed must have disappeared.

The idea of the proposed patch is to allow front-ends to make the same
assumption.

> For reference, this was due to bug 537338.

Thanks for the pointer --- that was very helpful.

Cheers,
Jonathan

Rough patch teaching APT to report "processing: disappear" lines:

=== modified file 'apt-pkg/deb/dpkgpm.cc'
--- apt-pkg/deb/dpkgpm.cc	2010-03-26 15:04:49 +0000
+++ apt-pkg/deb/dpkgpm.cc	2010-04-09 05:07:54 +0000
@@ -50,6 +50,7 @@
     std::make_pair("configure", N_("Configuring %s")),
     std::make_pair("remove",    N_("Removing %s")),
     std::make_pair("purge",    N_("Completely removing %s")),
+    std::make_pair("disappear", N_("Noting disappearance of %s")),
     std::make_pair("trigproc",  N_("Running post-installation trigger %s"))
   };
 
@@ -407,7 +408,8 @@
       'processing: install: pkg'
       'processing: configure: pkg'
       'processing: remove: pkg'
-      'processing: purge: pkg' - but for apt is it a ignored "unknown" action
+      'processing: purge: pkg'
+      'processing: disappear: pkg'
       'processing: trigproc: trigger'
 	    
    */