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

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



Question regarding this new bug on procmail-lib that I adopted recently:

----- Forwarded message from Matt Zimmerman <mdz@debian.org> -----

Subject: Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
Reply-To: Matt Zimmerman <mdz@debian.org>, 112121@bugs.debian.org
Date: Wed, 12 Sep 2001 20:37:25 -0400
From: Matt Zimmerman <mdz@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>

Package: procmail-lib
Version: 1:1997.07.22-1
Severity: serious

Being architecture-independent data, the .rc files supplied by procmail-lib
should go under /usr/share, not /usr/lib.

See Debian Policy 10.1.1, FHS 4.4, 4.7


-- System Information
Debian Release: unstable
Architecture: i386
Kernel: Linux mizar 2.4.8 #1 Sat Aug 18 20:31:53 EDT 2001 i686
Locale: LANG=C, LC_CTYPE=en_US

Versions of packages procmail-lib depends on:
ii  perl [perl 5.6.1-5                       Larry Wall's Practical Extraction 
ii  procmail   3.21.20010830.really.3.15.2-2 Versatile e-mail processor.

-- 
 - mdz


----- End forwarded message -----

Matt is correct, and if I was packaging from scratch that is how I would
have done it; however, I adopted this package in its state.

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.

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.

-- 
Elie Rosenblum                 That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer             - _The Necronomicon_



Reply to: