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

[POLICY] Binary vs source package names



Hi there!

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
reasons:

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 [3] or cl-irc [4].
>> >
>> > 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 [5] or StumpWM [6]), but not for
>> > all (e.g. Hunchentoot [7] 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
> CL.

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.

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20080611/9f39274f/attachment.pgp 


Reply to: