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

[Luca Capello]

Hi Juanjo!

On Sun, 07 Sep 2008 18:51:30 +0200, Juan Jose Garcia-Ripoll wrote:
> 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.

I used LSB as an example, here: I don't think that ECL will be part of
LSB, but this is an effort to uniform GNU/Linux distributions.  That's
why I don't like Debian packages deviating from upstream without a
consensus.

> 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 (*).

Thank you.  If I could say more, I really prefer full dates (YYYYMMDD),
but this is not the scope of this bug report.

> But let me remark that in this "bug" report we have not yet talked
> about the compiled files that ECL ships with.
[...]
> 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?

I didn't think about it before your mail because I don't see the
problem, really, please read below.

> 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.

Iif I understand correctly, we can have standalone programs [1] that
need just /usr/lib/libecl.so and others that need more than that,
i.e. all the other compiled files ECL ships in /usr/lib/ecl/ (these are
internal libraries, not shared ones).

With the actual situation, one cannot discriminate the dependencies
between the two cases (since the library is shipped together with the
compiler) and thus people should always depend on the full ecl_1-1
package.

However, if my words above are correct, I can split ecl_1-1 into two
packages, libecl [2] and ecl [3], the latter depending on the former.  This
means that if the standalone program I wrote works just with the shared
library, I don't need to install the other internal libraries and the
compiler.  Could this improve the situation?

I'd really like to have this bug fixed in lenny [4], but I don't
guarantee anything :-D

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

Fully ACK, please do it!

Thx, bye,
Gismo / Luca

Footnotes: 
[1] New manual: "1.6.3. Example of standalone program"
[2] actually, I still need to document myself about binary package names
    for shared libraries, thus the name could finally be libecl$SONAME
[3] FWIW, the next ECL Debian package will depends on GCC:
    http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=495351#25
[4] http://lists.debian.org/debian-devel-announce/2008/09/msg00000.html
-------------- 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/20080909/cfae279a/attachment.pgp