On 2012-07-11 21:47 +0200, Bart Martens wrote:
> On Wed, Jul 11, 2012 at 07:44:34PM +0200, Sven Joachim wrote:
>> On 2012-07-11 19:07 +0200, Sven Joachim wrote:
>> > On 2012-07-11 18:53 +0200, Bart Martens wrote:
>> >> In my opinion, regardless of the order in which these two packages are
>> >> installed, dpkg should fail to install the second package, with an error
>> >> message about /usr/include/tcl.
>> >
>> > Policy (ยง6.6) actually documents this behavior:
>> >
>> > A directory will never be replaced by a symbolic link to a
>> > directory or vice versa; instead, the existing state (symlink or
>> > not) will be left alone and `dpkg' will follow the symlink if
>> > there is one.
>>
>> And changing it would break quite a few things.
>
> Examples of those things ?
Local admin has set up (say) /usr/share/doc as a symlink rather than a
plain directory. Not really recommended, but according to your plan
they would not be able to unpack any package until they fix that.
Package foo converts (say) /usr/share/doc/foo into a symlink in the new
version. There is no standard procedure for that right now[1], but the
sanest way is to do it in the postinst (look at the libpipeline-dev
package for an example). With your proposal this becomes impossible,
and instead the package needs to rm -rf the directory in the preinst
instead, losing files if unpacking fails.
If other packages that share the same directory are involved, this
becomes even trickier.
> How to reproduce those breakages ?
Modify dpkg to fail in the above situations; this is left as an exercise
for you. ;-)
Cheers,
Sven
1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583585
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
