Bug#41113: Proposal: Naming Conventions for modules
Gregor Hoffleit wrote:
>I'm not sure, but I think debian-java adopted a similar naming
>convention for their Java extensions; at least this is halfways true
>for the two packages I found in the archive (libpgjava and
>libgnu-regexp-java) and for the packages I saw discussed in the
The Debian Java convention is just a proposal, in the present state of art.
The naming scheme for packages was shamelessly copied from Perl, because I was
most familiar with it.
>(1) Package names tend to get (too) long
> E.g. on a `dpkg -l "*-perl"', the "-perl" suffix is not visible for
> most packages. This will be worse for the longer string "-python".
This is a f... bug from dpkg and I saw it happening even without 'lib'.
> Java extensions are called packages.
> Now why should genuine Python modules get a "lib" component in their
> package name ?
Because C conventions tend to be Unix conventions?
>The "-perl" suffix already identifies a package as an Perl extension
>module (like our current "python-" prefix or the "-java" suffix),
>therefore the "lib" prefix is somehow superfluous, and makes the name
>unneccessary long. What exactly is the benefit of the "lib" prefix and
>is it worth the odds ?
For Java, and I suspect it is the same for Python, the rationale is the
- for programs, i.e. stuff that can be run by end users, the language does not
matter. If I need a personal Web proxy with ads filtering capabilities, I use
Muffin, regardless of the fact it is written in Java. Hence, we should not add
the language name in the package name. And we do not add 'lib' or any prefix.
- for libraries, Java does not have the C difference between -dev and runtime
libraries. But I believe it is useful to separate programs (which have an
utility by themselves) from libraries (which are here only for the convenience
of programs). Hence a prefix, which is, IMHO, simpler to recognize if it's the
same for all languages, regardless of their terminologies. And, since you
cannot use a library for an interpreted language without knowing its language,
it makes sense to have the language name into the package name.