Re: Source package names for R libraries (and Perl, Python, Java, …).
On Wednesday, February 15, 2012 10:50:57 AM Don Armstrong wrote:
> On Wed, 15 Feb 2012, Charles Plessy wrote:
> > To follow the naming scheme of the Perl team, I have renamed one of
> > my binary packages ‘bioperl’ to ‘libbio-perl-perl’, but I doubt it
> > would be helpful to have such a name as a source package.
>
> Perl common practice is to use the same source and binary package
> names. The only exceptions I'm aware of are for perl modules bundled
> with upstream distributions or things which were packaged in the mists
> of time.
>
> > Then, if one choses a Debian-specific name for an upstream work, it
> > is advantageous to keep the same name for the source and binary
> > package, and for R and Perl, there are conventions in place.
>
> Right; the primary reason why that is done is because CPAN is the only
> perl repository, whereas R has multiple separate repositories, so
> namespace conflicts are not enforced like they are in the CPAN world.
> [This balkanization is kind of silly, but that's not really something
> we can solve in Debian.]
>
> > An additional complication comes when a source package produces more
> > than one binary package, for instance a R and a Perl library at the
> > same time. The convention on the source package name is therefore at
> > best a “should”.
>
> The exceptions can be specifically delineated, as they are cases where
> you 1) ship multiple binaries 2) ship binaries which encode a version
> number. [This basically means that if you're not creating a shared
> library, at least one of the packages you distribute should have the
> same name as the source package.]
>
> > On top of this, the benefit of of having a policy on source package
> > names will be limited as it is unlikely to rename the existing ones.
>
> The main benefit is avoiding unnecessary utilization of the source
> package namespace, the secondary benefit is eliminating the current
> problem of users misreporting bugs against the wrong package due to
> confusing the source↔binary naming. [It is this second problem that I
> continually have to deal with, and why I'm particularly aware of it.]
>
> > Let's try to agree on a brief policy on naming schemes. Perhaps
> > Perl, Python and Java maintainers can comment on whether it would
> > make sense to have a common one (drafted as a DEP ?).
>
> A DEP or just a policy amendment specifying the general naming
> requirements with pointers to language specific naming policy would
> work.
While I agree that preserving namespace is an important goal, I think it
should be balanced against the goal of making packages discoverable by users.
If they can find the source package by the upstream name (where it doesn't
match the language specific policy requirement) then usually they can find the
binary (or worst case a bug gets mis-filed against the source and the
maintainer still finds out).
As an example, one of the packages I maintain is known upstream as pyspf. The
Debian python naming requirement for the binary is python-spf. Since the
upstream name is python specific and not likely to collide, I think having the
source package match the upstream name (as it does) is quite reasonable.
I also maintain python-ipaddr. Here the upstream name was ipaddr. This
seemed like far to generic a name to 'use up', so I named the source package
after the binary, python-ipaddr.
Whatever rule you come up with, I don't think it's one size fits all.
Scott K
Reply to: