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

[Juan Jose Garcia-Ripoll]

On Sun, Sep 7, 2008 at 2:18 AM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

> > Well, I really think SONAME's decision belongs to developers, not to
> > package maintainers.  Let's say that Debian uses a SONAME of 0.1 while
> > Ubuntu 0.2 [1]: then every effort done with the LSB [2] is lost.
>
> This indeed would be unfortunate.  Just as ECL developers control ECL
> release versioning, I believe most people would naturally assume that
> ECL developers control ECL SONAMEs.  At least, that is the way it works
> for most projects.


Well, for one I do not believe in LSB. At least I do not believe people are
going to include ECL in the list of required software by the LSB committee,
and that implies no program can expect it is going to have the right version
of the ECL runtime waiting for them in the host machine. It does not matter
whether the SONAMEs are right or not.

Now, given that everybody asks me to maintain SONAMEs and not only that, but
to add the proper flags for the linker, and since you must have guessed I am
a lazy guy and I do not believe I will be able to maintain by myself binary
compatibility among releases, I just announce that the SONAMEs will end up
being dates: (format nil "~D.~D" (- year 2000) month) of the code I produce
(*). I still really wonder the utility of this.

But let me remark that in this "bug" report we have not yet talked about the
compiled files that ECL ships with. If somebody links against ECL version
x.y.z it is going to expect that the compiler is also there and it works
with the same implementation. And the sockets library as well. That means
not only the library file will have to be versioned, but the library
directory in which ECL is installed as well. Have you thought about this?

So, again, ECL is closer to SBCL or python (**) that what you may think in
that it is a runtime. It is true that programs may embed its library, and it
is true that the software installs libecl.so in the /usr/lib directory, but
this was not always the case and I only changed it because I was asked to
remove all uses of --rpath from my code.

Juanjo

(*) Actually, given that people have also complained about my versioning
scheme, I may just as well do that for real version numbers.

(**) With the exception that python has a probably larger span between
releases and it is more stable forced by the large userbase.

-- 
Instituto de Física Fundamental
CSIC, Serrano, 113, Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20080907/41e814ae/attachment.htm