FYI: Alexander Reelsen filed bug#41113 against debian-policy, which
is of interest for debian-java, debian-python as well as debian-perl:
On Sun, Jul 11, 1999 at 11:10:22PM +0200, Alexander Reelsen wrote:
> The following is a proposal to add some rules to the debian policy concerning
> the naming conventions for modules, ie perl- and pythonmodules.
>
> Earlier, when I was not debianized that way I am now, I installed Perl/Tk
> called perl-tk. Then, I tried to install Gtk-Perl (its current name, if I
> remember right). I thought it was called perl-gtk, but it is/was called
> libgtk-perl. Now I know, most modules are named libfoo-bar-perl and not
> perl-foo-bar.
> So, a few days ago I installed python and lots of modules. They have all got
> the name naming scheme (at least those I installed), namely python-foo-bar.
> That was the point in time I was completely confused.
>
> Long story, short proposal:
> In my opinion we should get a stricter policy on this problem, else we will
> lose the overview of all those modules (although most maintainers name the
> modules after the standard scheme). It should be decided whether the modules
> start with libfoo-bar-language or with language-foo-bar. Both is a bad mix.
> Switching the programming language and the scheme of searching for modules is
> IMHO not a solution and not the intention I think/hope.
Currently, the Python maintainers have an implicit policy to use a
naming scheme of python-foo-bar for all Python extension modules.
If Alex proposal gains support, we may have to change this convention
to something like libfoo-bar-python (as I don't think the Perl people
would be glad to change their package names ;-).
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.
Personally, I don't not like libfoo-bar-python (nor do I like
libfoo-bar-perl) for a few reasons (but perhaps you can convince me
that a conversion still has more benefits than odds ;-):
(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".
(2) We don't follow the conventions of the languages communities
C extensions are called libraries.
Python extensions are called modules.
Perl extensions are called modules.
Java extensions are called packages.
Now why should genuine Python modules get a "lib" component in their
package name ?
(3) It makes it harder to find a package by its upstream name
Many Python extensions follow an upstream naming scheme of
python-foo. Converting this to libfoo-python makes is harder to
locate these packages.
AFAICS, Perl's convention regarding package names is a consequence of
the Debian Policy for C libraries (Debian Policy 4.3 Shared
libraries):
C library files tend to have a name libfoo (e.g. for the sake of the
linker's -lar option ;-). There's some good rationale behind this and
it's in sync with the common practice. As a consequence, Debian policy
mandates (4.3 Shared libraries) that packages included shared
libraries have to follow the librarynamesoname convention (with
optional packages librarynamesoname-dev and
librarynamesoname-runtime), e.g. libgtk1.2 for Gtk 1.2.x.
Now the rationale behind Perl's naming conventions is that Perl's Gtk
module is closely related to the Gtk C library, aka libgtk. To stress
this relation, the Perl package is called [libgtk]-perl in favor of
something like perl-gtk. This sounds reasonable.
Still, IMHO it doesn't make too much sense for genuine Perl extensions
like libi18n-charset-perl, where there's no base package
libi18n-charset that would motivate the "lib" prefix.
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 ?
As a starting point for discussions, I would propose those three
alternatives for a Python modules' naming sub-policy:
(1) Keep the current Python scheme: Stay with the upstream name if
possible. A rule of thumb is "python-foo-bar" (i.e. pyfoo-bar will be
python-foo-bar).
(2) If the extension is just a wrapper/interface for an existing
package foo-bar, we'll call it foo-bar-python. Therefore, pygtk would
become libgtk-python (just like libgtk-perl). If the extension is a
genuine Python module, call it python-foo-bar.
(3) The current perl scheme: Call the package libfoo-bar-python.
I guess the preferences of the Python maintainers are at (1). Still,
perhaps we can discuss this and come to a more general solution that
satisfies most concerns.
Gregor
