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

Re: Bug#41113: Proposal: Naming Conventions for modules



-----BEGIN PGP SIGNED MESSAGE-----

Stephane Bortzmeyer <bortzmeyer@debian.org> writes:
> >    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?

I would argue that neither C conventions *nor Unix conventions* are
particularly relevant to Python, Perl, or Java.  All of the languages
we are discussing here are, in some sense, independent of the
operating system on which they run.

As a result, I believe that in choosing a naming convention, we should
pick one that best represents the conventions and terminology of the
upstream language community and the wishes of the corresponding Debian
packagers, rather than one that is somehow more Unix-like.

In fact, I personally find the "lib<foo>-<language>" convention to be
quite confusing.  To me, "lib<foo>" is the Unix convention for a *C
library*, and having it also be used for Perl (which does not follow
that same convention upstream) is a constant annoyance.  If the Perl
packagers like that naming scheme, so be it; however, I do not want to
see a policy enacted that forces me to use the same non-intuitive,
confusing convention on my own packages.

Also, having the language name first means that libraries for a
language sort together.  Even if dpkg and dselect were fixed to more
readily display long packages names, sorting them together is a
natural grouping.  Which is less confusing: having 1000 packages in
four languages listed together in one big lump?  Or having nicely
separated groups, "lib" for C stuff, "perl-" for Perl, "python-" for
Python, "java-", etc., so that you can easily find everything Debian
has for a particular language?

On a more practical level, the Python packagers are already following
the convention of naming packages "python-<foo>".  Changing that would
require all of the Python add-on packages (and dependencies on them)
to be renamed.  Personally, I would rather codify the existing
convention, than force such a renaming.

- --Rob

- -- 
Rob Tillotson  N9MTB  <robt@debian.org>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface

iQCVAwUBN5EDPnR+ngWruQ4VAQE/QAP+OY83N1gPw6VfKfvw5QISh7S5kfYlGwrD
dVjMXnCRc2O6UUc4HTt2pRW6p4avcvI4orR6DX/WQ7njO6AGJ7eM1O3gYsoQA31c
SuluBj3FSfBzR+M+sMxrh7iNKtm1tMNQRrLvtXeHUV3y9sv9i9rxMr0OqYT8VTNC
el8P24Op+UM=
=QCzT
-----END PGP SIGNATURE-----


Reply to: