[Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

[Luca Capello]

Hi Juanjo!

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.

Noted, thanks.

>   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 [1].  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.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 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
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20080910/89a4e201/attachment.sig>