Re: possible mass-filing of bugs: many shared library packages contain binaries in usr/bin
Richard Braakman <email@example.com> writes:
> Hmm, but it does not achieve that. lib will still contain all kinds of
> architecture-dependent data, such as the dictionaries in /usr/lib/ispell
> and the stuff in /usr/lib/megahal. Separating the executables will only
> address one category of many.
Right. Splitting lib and libexec does not solve all problems.
The files you specify are explicitly disallowed by the GNU Coding
Standards--you aren't supposed to have static architecture-dependent
data, for the simple reason that it's basically always better to write
the program to use an architecture-independent format.
But that has nothing to do with Debian, and the GNU Coding Standards
are instructions for programmers, not for Debian developers. Debian
developers should not be expected to rewrite programs the way the
GNU Coding Standards suggest, and need a place to install such files.
For the argument you suggest, there should be a place. The historical
directory is "libdata", which comes from the same source as libexec,
and was created at the same time. I would certainly support adding
libdata to the FHS, though since I concur with the opposition of the
GNU Coding Standards to architecture-dependent static data, I would
not want to see it added there.
> The difference between bin and sbin is visible to the user, however.
> It is functional. I see no function for libexec.
If the user uses -l, then it is visible.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com