Re: Renaming a package
On Fri, Jun 02, 2006 at 09:19:42AM +0200, Andreas Fester wrote:
> Absolutely. Its also the method I would prefer because it adds minimal
> overhead providing the most seamless upgrade. I implemented it for my
> package, and the first test succeeded very well (amd64 testing/unstable),
> but today I tried it on another machine (i386 testing/unstable) and it
> failed with
>
> # apt-get dist-upgrade -V
> Reading package lists... Done
> Building dependency tree... Done
> Calculating upgrade...Done
> The following NEW packages will be installed
> crossvc (1.5.0-1)
> The following packages will be upgraded:
> lincvs (1.4.4-2 => 1.5.0-1)
> ...
> Get: 1 http://littletux.homelinux.org unstable/non-free lincvs 1.5.0-1 [744B]
> Get: 2 http://littletux.homelinux.org unstable/non-free crossvc 1.5.0-1 [1289kB]
> Fetched 1290kB in 27s (47.0kB/s)
> (Reading database ... 82122 files and directories currently installed.)
> Preparing to replace lincvs 1.4.4-2 (using .../lincvs_1.5.0-1_all.deb) ...
> Unpacking replacement lincvs ...
> Selecting previously deselected package crossvc.
> Unpacking crossvc (from .../crossvc_1.5.0-1_i386.deb) ...
> (Noting disappearance of lincvs, which has been completely replaced.)
> Setting up crossvc (1.5.0-1) ...
>
> dpkg: error processing lincvs (--configure):
> no package named `lincvs' is installed, cannot configure
> Errors were encountered while processing:
> lincvs
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> # dpkg --version
> Debian `dpkg' package management program version 1.13.19 (i386).
Oh crap. This looks exactly like a reincarnation of #202997 which is
supposed to be fixed since 1.10.22. Let's see... In fact, it still works
fine when using 'dpkg -i oldpkg newpkg'. However, apt splits it up into
'dpkg --unpack oldpkg newpkg', 'dpkg --configure oldpkg newpkg', and
doesn't notice that oldpkg has vanished inbetween. I wonder why it used
to work for me before. In any case, this rules out using this method for
etch. If we want to have it available for etch+1, we could either teach
apt about disappearing package or change dpkg to ignore attempts to
configure package that are not installed instead of spitting out an
error. I don't know how hard it would be to change it in apt (deity list
Cc'ed therefore), but the alternative patch to dpkg is quite simple (see
below). Alas, it changes current behaviour.
Regards,
Daniel.
--- src/packages.c.orig 2006-06-02 14:40:47.000000000 +0200
+++ src/packages.c 2006-06-02 14:41:06.000000000 +0200
@@ -191,11 +191,11 @@
assert(dependtry <= 4);
}
switch (cipaction->arg) {
+ case act_configure:
case act_install:
/* Don't try to configure pkgs that we've just disappeared. */
if (pkg->status == stat_notinstalled)
break;
- case act_configure:
deferred_configure(pkg);
break;
case act_remove: case act_purge:
Reply to: