Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME
luca at pca.it
Tue Sep 9 22:27:04 UTC 2008
On Wed, 10 Sep 2008 00:10:10 +0200, Juan Jose Garcia-Ripoll wrote:
> On Tue, Sep 9, 2008 at 11:15 PM, Luca Capello <luca at pca.it> wrote:
> I'll play the Devil's advocate here, sorry: does this mean that 0.1.0
> will be SONAME-compatible with 0.1.1?
> The SONAME only uses the first two numbers.
> Also, what is definitely true is that two libraries with different
> major (i.e. first) or minor (i.e. second) release numbers are not
> guaranteed to be binary compatible.
> Is a new release planned soon or should I package today's CVS snapshot
> to close this bug?
> One or two weeks. Depends on another bug being closed and also how
> life develops.
OK, I'll ask the Debian Release Team about uploading a new upstream
version at this time frame and then react accordingly.
> CLISP provides a similar situation, but we (i.e. Debian) decided to ship
> only one version. What's your advice here?
> I do not think it is politically correct to ask the maintainer of one
> implementation how the packaging of a different one should go, so
> please excuse if I do not answer that question.
I understand your point, but I think I wasn't enough clear: my question
was/is not about how Debian should package CLISP, but what you prefer
for ECL. Let's try again with different (and maybe clearer) words.
I prefer to keep the ECL situation as it is now: Debian ships only one
version, which is the latest release . This means less work for the
Debian maintainers (ATM mostly me) and also a more closer tracking of
upstream development. The disadvantage is for anyone depending on ECL,
who needs to "port" her/his applications to the new upstream release.
Is it OK for you or have you other suggestions?
I still think that splitting the main binary package into ecl and libecl
can improve the situation WRT dependencies, but this is another matter.
Gismo / Luca
 considering the Debian policies, i.e. if Debian's freezing for a new
stable release, no new upstream versions are allowed in testing
-------------- 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/20080910/89a4e201/attachment.pgp
More information about the pkg-common-lisp-devel