Re: Perl Policy interpretation issue (was Re: Bug#174593: libxml-parser-perl contains sharable files in /usr/lib)
On Sun, 29 Dec 2002, Raphael Hertzog wrote:
> Suppose that we have ModuleXS and ModuleIndep in the same "package". You
> want me to install ModuleIndep in /usr/share/ and ModuleXS in /usr/lib
> because we can share /usr/share across various architectures.
>
> Fine. Now suppose that ModuleIndep does "use ModuleXS" and that it's useless
> without ModuleXS, what's the point of sharing ModuleIndep ?
Well, then it's the fault of the admin who doesn't provide ModuleXS on such a
machine.
> You're just taking the risk to make a broken module available to
> machines that don't have the corresponding binary modules ... on the
> contrary if ModuleIndep is packaged with the binary module in the same
> directory, this would never happen.
>
> > FHS doesn't classify files by what you do with them. They classify them by
> > type. And .pm files are sharable. So into /usr/share they go.
>
> That's bullshit. We have plenty of files in /usr/lib/ which are not
> "arch-specific" : check /usr/lib/dpkg/methods/ for example.
Historical(histerical) reasons. It doesn't mean the above example is correct.
File a bug if you want the above moved. But, doing an upgrade would be fun to
work out.
> All files in "/usr/share/" must be shareable. But nothing says that all
> files in /usr/lib/ must be arch-dependant. We put files in
> /usr/share/ when the files are shareable and when it makes sense to
> share them.
Fine. Make me quote.
/usr/share/doc/debian-policy/fhs/fhs.html/fhs-4.3.html, section 4.4:
4.4 /usr/lib : Libraries for programming and packages
/usr/lib includes object files, libraries, and internal binaries that are
not intended to be executed directly by users or shell scripts.
(See the above? In the example for this bug report, users *can* use the .pm
directly.)
Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application should be placed within that
subdirectory. For example, the perl5 subdirectory for Perl 5 modules and
libraries.
Miscellaneous architecture-independent application-specific static files
and subdirectories should be placed in /usr/share.
(See here as well? FHS says to place these .pm files in /usr/share.)
[snip part about /usr/lib, sendmail, makewhatis, and catman]
[snip part about /usr/lib/x11]
> That's my opinion, I won't argue much more. I think I explained why
> it makes sense to keep some arch-indep modules in /usr/lib/. I think
> that the rationale I gave is enough to modify the perl policy
> accordingly. Now I'll let the policy crew do the rest. :)
Well, I've provided ample evidence to prove you wrong.
Reply to: