Re: Mistake in postrm preventing functioning of newer package (stable/testing/unstable)
On 2011-09-09 13:43 +0200, Colin Watson wrote:
> On Fri, Sep 09, 2011 at 12:54:32PM +0200, David Paleino wrote:
>> On Fri, 9 Sep 2011 12:42:11 +0200, sean finney wrote:
>> > Another option, as awful as it sounds, is to nuke (or surgically modify)
>> > the postrm script of the old package from the preinst of the new package.
>> > You would need to support that until the current stable was rotated out
>> > through oldstable. Yes, awful. But I've seen it done before...
>>
>> I didn't think to that, and it seems the only solution to ensure clean
>> upgrade paths.
>>
>> I'll use the 'old-version' parameter passed to preinst on upgrade, and check
>> if it's less than the current version in sid.
>>
>> Will someone kick me hard if I go this way? :)
>
> I still have such code in man-db.preinst (albeit for upgrades from rex
> or so, but I don't believe in dropping upgrade compatibility :-) ), so I
> at least would have no grounds for doing so if you get it right ...
I think there is no real way to get it right, but the path to the postrm
script should at least be obtained with "dpkg-query -c <package> postrm"
rather than assumed to be /var/lib/dpkg/info/<package>.postrm .
Sven
Reply to: