Question regarding this new bug on procmail-lib that I adopted recently: ----- Forwarded message from Matt Zimmerman <[EMAIL PROTECTED]> -----
Subject: Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib Reply-To: Matt Zimmerman <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Date: Wed, 12 Sep 2001 20:37:25 -0400 From: Matt Zimmerman <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> 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_