[Pkg-mailman-hackers] Bug#400005: Installs files in /var/lib/mailman in violation of FHS

[Lionel Elie Mamane]

On Fri, Nov 24, 2006 at 04:06:02PM -0800, Steve Langasek wrote:
> On Thu, Nov 23, 2006 at 01:41:08PM +0100, Lionel Elie Mamane wrote:
>> (Bug is present up to and including 1:2.1.9-2.)

>> Mailman installs architecture-independent program files not written
>> except at install/upgrade time in /var/lib/mailman/pythonlib/email/
>> . That's a gross violation of the FHS, which mandates /usr/ instead of
>> /var/ .

> I'm not sure I would call this a "gross violation" of the FHS,
> though I am surprised to see these .py files in /var/lib given that
> mailman has other .py files it's been shipping under /usr/lib
> forever.

The story is:

 - Mailman upstream ships with a copy of some modules of the Python
   standard library. (email, japanese and korean codecs)

 - Mailman in Debian disables these and makes Mailman use those from
   the ... Python standard library.

 - However, the email module of Python 2.4 breaks Mailman big time.

 - So I enabled Mailman's private copy of email, but failed to notice
   it gets installed in a _new_ directory which didn't exist in
   previous versions of the Mailman package.

>> 1:2.1.9-3 will make it /usr/lib/mailman/pythonlib/email, which is
>> still suboptimal (the non-compiled files should be in /usr/share,
>> being architecture-independent), and may technically still be a
>> violation,

> I don't believe this is a violation of the FHS.  The release policy
> has recently been updated to clarify precisely this.

Oh, good. We won't have to move these files then. Thanks for that
information.

>> (the files are compiled at install/upgrade time; the compiled
>> versions must be in /usr/lib; not sure there even _is_ a way to
>> have sources and compiled versions separated in Python - if any
>> Python expert can contradict me on that, please do!

> With the recent python helpers, it's common practice to ship the .py
> files under /usr/share, then symlink them to /var/lib for
> byte-compiling.

Actually, I learnt that even the compiled versions are
architecture-independent.

These are private modules (not to be exposed to other Python
applications), so to the best of my understanding, the "recent python
helpers" won't move / symlink them anywhere else than where the
package puts them.

-- 
Lionel