[POLICY] Binary vs source package names
luca at pca.it
Tue Jun 10 22:39:17 UTC 2008
Please don't Cc: me, I read the list.
Thiemo, I re-added some part of Liam's mail to avoid two replies :-D
On Sun, 08 Jun 2008 07:17:44 +0200, Thiemo Seufer wrote:
> Liam Healy wrote:
>> I don't have any Debian packages, but I don't like this.
>> I've come to dislike the "cl-" prefix for anything, because it
>> implies that the language in which the software is written in is the
>> most important thing. I don't see "c-" "perl-" etc. for other
>> languages, I don't see why lisp should be any different.
> I agree.
While for C there's no c- prefix, most of the C libraries are called
"lib$UPSTREAMNAME", which is mostly the same. And for Perl you don't
have any prefix, but a suffix (e.g. libapt-pkg-perl). Another language,
Ruby, gets a more awful suffix (e.g. libdpkg-ruby1.8).
Upstream when obliged to choose already use the cl- prefix, which means
that we try to follow upstream whenever it's possible.
>> Why is there a need for a policy at all? Why not just let the
>> authors name the packages as is traditional?
With more than 18000 binaries available in Debian, you need a way to
distinguish between package names, especially when more binary packages
can have a similar name. What if cl-syslog upstream would have decided
to call her/his project simply "syslog"?
> Furthermore, changing package names without good technical reasons is
> gratuitous and only adds trouble for existing users. (Following the
> upstream default might be a strong enough argument to change it, as
> this reduces long-term confusion.)
I agree that randomly changing package names is not accepted, but in
this case I see this for Hunchentoot as no pain for at least two
1) Hunchentoot is not in Etch, IIRC this means that we can even ships
only the new package 'hunchentoot' without a migration path. If you
don't want trouble, you are advised to use 'stable': not that I'm
this kind of maintainer, but at least we don't need to carry
cl-hunchentoot for two releases, since we can drop it as soon as
Lenny is released (but we need to keep "Provides: cl-hunchentoot")
2) We're not moving from no prefix to prefix, but the other way around:
upstream is called Hunchentoot and we want to follow upstream
I still think this is the Right Thing™ for Hunchentoot and I'll wait two
more days before changing the binary name back to 'hunchentoot'.
>> On Sat, Jun 7, 2008 at 11:29 AM, Luca Capello <luca at pca.it> wrote:
>> > My proposal is that "libraries" should have the cl- prefix at least
>> > for the binary package names, since this is very similar to the
>> > lib* packages. With "library" I mean all those software which is
>> > designed to be used by other packages and not as a stand-alone
>> > program. E.g., arnesi  or cl-irc .
>> > However, binary package names for software which is intended as a
>> > stand-alone program should not be prefixed by cl- if they don't
>> > already have it. Whenever is possible, the source package name
>> > should reflect the upstream one, thus without the cl- prefix if
>> > upstream doesn't have it. This is indeed the case for most of the
>> > software in this group (e.g. SBCL  or StumpWM ), but not for
>> > all (e.g. Hunchentoot  binary package is called cl-hunchentoot
>> > in Debian).
>> As for being a library, I view everything as a library, particularly
>> in lisp. Software should be as easy for other software to use as it
>> is for people; that is something that lisp facilitates.
> The distinction beween applications and libraries is rather weak in
I though that putting "library" in double quotes was a strong note about
the fact that me neither I see a clear distinction between an
application and a library in CL. However, some CL software is clearly
intended to be used by or in conjunction with others: this is (very?)
similar to what happens in C with libraries.
> Is there a good reason to follow the limitations of lesser languages?
No, but having a clear "policy" (maybe "guidance" would be better) could
finally help everyone in Debian.
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 314 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20080611/9f39274f/attachment.pgp
More information about the pkg-common-lisp-devel