[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
>debian-java list.

The Debian Java convention is just a proposal, in the present state of art. 
See <http://www.debian.org/~bortz/Java/policy.html>.

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.


Reply to: