[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib



On Wed, Sep 12, 2001 at 10:51:04PM -0400, Elie Rosenblum wrote:

> Question regarding this new bug on procmail-lib that I adopted recently:
> 
> [snip copy of my bug report]
> 
> I would happily move it to /usr/share, however I am worried about users
> who are already using the current version. Users can use the provided
> recipes with the procmail INCLUDERC directive, and if I move the files it
> will break all of the user rcfiles that already use these includes.
> 
> Would turning /usr/lib/procmail-lib into a symlink to the appropriate
> location be acceptable? I would really rather avoid breaking every rcfile
> that currently uses any of these recipes.

This, in particular, won't work, because dpkg won't replace a directory with
a symlink.  You could, however, replace the files themselves with symlinks,
and if you decide that it is important enough to transparently preserve
backward compatibility, I would recommend that you do that.

The files themselves would be in the correct place, and the documentation
should direct new users to reference them in the new location, and the
symlinks could be used for the sake of compatibility.

Regardless of whether you create the symlinks, you should definitely display
a warning note (via debconf) to the admin upon upgrading from an older
version of the package, advising them of the change and encouraging them to
update any procmail configs which include recipes from procmail-lib.  Then,
perhaps in a future release, you may decide to remove any compatibility
links, having given fair warning to the administrator (compare the
/usr/doc->/usr/share/doc transition plan).

> My real philosophical difficulty here is that this is a weird case - it is
> unlikely to burn admins, for whom I could add a notice of this during
> package upgrade; I am worried about the users in general.

You can't take too much direct responsibility for the users; you should keep
the admin well-informed, and let them communicate/deal with the users.  In
some sites, the admin might silently fix all of the users' configurations;
at another, they might send out an email announcement telling them to do it
themselves; another admin might leave it up to the users to fix their
configurations.  As the Debian maintainer, you can't be aware of local
policy.

-- 
 - mdz



Reply to: