[Piuparts-devel] Bug#720185: More information

Bastien ROUCARIES roucaries.bastien at gmail.com
Mon Aug 19 14:48:23 UTC 2013


On Mon, Aug 19, 2013 at 4:37 PM, Andreas Beckmann <anbe at debian.org> wrote:
> On 2013-08-19 15:38, Bastien ROUCARIES wrote:
>> You advice to
>> test -L symlink; then
>>    rm -f symlink;
>> fi
>>
>> It is really a bad piece of advice because:
>> - it remove custumised by admin symlink and thus is a policy violation
>> - it does not handle partial upgrade/failled install
>> - it does not handle downgrade.
>
> But at least it works for the majority of use cases: upgrades of
> non-customized systems. And partially for recovery from previous messed
> up upgrades. That should be at least better than having nothing at all.
>
> To fix this perfectly, the task should be handed over to a tool. Since
> the majority of the problems is /usr/share/doc/$PACKAGE switching
> between symlink and directory, dh_installdocs might be the appropriate
> place ...

See #659044 may I should add as blocking bug ?

> I'm not sure whether it is possible to get downgrades done correctly at
> all. Downgrades from a package shipping a symlink should probably
> unconditionally remove that link (if unmodified) in prerm - and let the
> old package install again anything it wants to have there.

Downgrade should test the version, and remove the link depending of the version

> For your question about affected packages, you can probably count the
> matching subjects from
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=piuparts;users=debian-qa@lists.debian.org&archive=both
>
> And these are only the ones I found with piuparts. And not all may use
> the same subject. Feel free to add another usertag to build a separate
> group.

Will do

> Hmm, we could test downgrades with piuparts, too, if someone (!= me)
> writes some patches ... I really don't want to open that can of worms.

You are welcome.

>
>
> Andreas
>
> PS: if a package ships a symlink, that gets customized by the local
> admin - upon upgrade, dpkg will restore the link to the shipped value -
> is that a policy violation, too? (no directory vs. symlink switching)

I think so.
>
> PPS: apt-get install foo ; customize ; apt-get remove foo ; apt-get
> install foo ; # which customization must survive (turning files,
> directories, symlinks into (different) symlinks)?

Ask clarification of policy ?



More information about the Piuparts-devel mailing list