Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Fri, Sep 14, 2001 at 10:50:42PM +0200, Josip Rodin wrote:
> On Fri, Sep 14, 2001 at 04:18:22PM -0400, Matt Zimmerman wrote:
> > ...and the new prerm remove it, and future versions of these scripts
> > until the end of ti^W^W^Wrelease after next...
>
> Actually, if you'd also ship the symlink in the new .deb, dpkg would
> remove it. Or am I missing your point?
I haven't actually tried this, so I'll take your word for it that dpkg
wouldn't complain about the symlink in the new .deb vs. the directory in the
filesystem.
When I had to do something similar with clisp, I sidestepped the issue by
symlinking the handful of files rather than the directory itself. It was
worth the small price of having the old directory continue to be present in
the .deb in order to avoid having to handle the whole bit in the maintainer
scripts (and deal with the bugs that almost always crop up).
Has anyone considered teaching dpkg how to handle this situation? One
possible solution would probably involve tracking type information
(file/directory/symlink) for filesystem objects rather than just names, and
allowing these to be slightly out of sync with the actual representation in
the filesystem (e.g., waiting until nothing is left under a directory,
except perhaps symlinks to the new location, and replacing it with a
symlink).
I seem to recall that 'stow' had a relatively smart mechanism for
expansion/collapse of symlinks that solved a related problem.
--
- mdz
Reply to: