Daniel Kobras <[EMAIL PROTECTED]> writes:
> 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.)
That means all files in lincvs have been replaced by crossvc.
But how can that be? Shouldn't there be a
/usr/share/doc/lincvs/Changelog.gz or /usr/share/doc/lincvs -> crossvc
link left in lincvs?
Or is that really intendet so the dummy package uninstalls (disapears)
on its own?
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
