[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Renaming a package

>> Method B
>>   Package: oldpkg
>>   Depends: newpkg
>>   Files:
>>     /usr/share/doc/oldpkg -> /usr/share/doc/newpkg
>>     (and nothing else)
>>   Package: newpkg
>>   Replaces: oldpkg
>>   Provides: oldpkg
>>   Files:
>>     (...)
>>     /usr/share/doc/oldpkg -> /usr/share/doc/newpkg
>> Method A relies on the user or external programs like deborphan to clean
>> up the dummy package. Method B gets rid of it automatically, using a
>> dpkg feature, but requires an extra symlink in newpkg.
> Oooh, Method B is one I haven't seen proposed before in the context of dummy
> packages.  That looks far more elegant to me than the alternatives.  Have

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:
E: Sub-process /usr/bin/dpkg returned an error code (1)

# dpkg --version
Debian `dpkg' package management program version 1.13.19 (i386).

So first it seems that dpkg gets the right idea
that the dummy package has been completely replaced, but then
why does it want to configure it?



Reply to: