[Piuparts-devel] Bug#720185: More information

[Andreas Beckmann]

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 ...

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.


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.


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.


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)

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)?