Re: Shall we state about #17624 dpkg feature(bug?)
On Tue, Jul 24, 2001 at 01:15:07PM +1000, Anthony Towns wrote:
> On Mon, Jul 23, 2001 at 08:58:58PM -0400, Matt Zimmerman wrote:
> > On Mon, Jul 23, 2001 at 05:34:35PM +0200, Wichert Akkerman wrote:
> > > * The system administrator can have created that symlink manually in
> > > order to distribute files differently over his filesystems, in which
> > > case we should not change it into a directory silently.
> > Isn't the system administrator is discouraged from manipulating filesystem
> > objects that should be under the control of the packaging system? If
> > she wants to distribute files over different filesystems, there are better
> > ways (like mount, especially in 2.4.x).
>
> No, she's not. Using symlinks (especially before 2.4.x) is the supported
> way of rearranging things.
Is this mandated in policy somewhere? I can't find a reference. If symlinking
about in package-owned space is supposed to be supported, then there are a lot
of broken packages in the distribution. On my system there are some 545
relative symlinks in /usr alone, excluding /usr/doc. All of these would be
broken by replacing various directories with symlinks to directories at a
different level in the tree.
One place in policy where this is obviously *not* supported is 13.4. Accessing
the Documentation, where the use of a (relative) symlink is suggested for the
/usr/doc->/usr/share/doc transition. Anyone who has symlinked /usr/doc to
someplace else would not get any compatibility symlinks, and would end up with
missing documentation.
> > I don't quite understand what you're saying. What would cause those other
> > files to disappear? The symlink could be unpacked as foo.dpkg-new, then the
> > old directory removed and/or renamed and the symlink switched into place.
>
> [...]
> With nowhere to put 'a' and 'b'.
Yes, Wichert explained in another message and I understand what he meant now.
--
- mdz
Reply to: