[Piuparts-devel] Bug#720185: More information

[Bastien ROUCARIES]

On Mon, Aug 19, 2013 at 4:48 PM, Bastien ROUCARIES
<roucaries.bastien at gmail.com> wrote:
> 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.
I think it is #182747

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