Embeddable Common-Lisp

Hi there!

Please respect the R-T and M-F-T headers, i.e. replies to the Debian bug
report as well (no subscription needed).

On Mon, 25 Aug 2008 23:51:05 +0200, Luca Capello wrote:
> This is a bug in the Debian BTS:
>
>   http://bugs.debian.org/486376

This bug has nothing to do with the rpath issue (now solved [1]).
Thus, the problem remains: is there any particular reason for
/usr/lib/libecl.so not providing a SONAME?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/495756

On Sat, Aug 30, 2008 at 1:07 AM, Luca Capello <luca@...> wrote:
> This bug has nothing to do with the rpath issue (now solved [1]).
> Thus, the problem remains: is there any particular reason for
> /usr/lib/libecl.so not providing a SONAME?

That is not something ECL has to provide. It is more a configuration
option that operating systems may provide. The question is whether it
is worth.

You have to consider the following: with every binary release we are
adding more functions and the names of old ones change. That means
being a rapidly evolving project we are definitely going to break
binary compatibility very frequently. I should rather say with every
release.

Furthermore, ECL is currently not being used as a library by any
project. It is only either a runtime for compiled files or the
interpreted environment itself. Do you expect SBCL to use some kind of
SONAME for its core? Not really.

Juanjo

-- 
Instituto de Física Fundamental
CSIC, Serrano, 113, Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

On Sat, Aug 30, 2008 at 2:19 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll@...> wrote:

> Furthermore, ECL is currently not being used as a library by any
> project. It is only either a runtime for compiled files or the
> interpreted environment itself. Do you expect SBCL to use some kind of
> SONAME for its core? Not really.

well, libecl.so does act like a library.  It is my experience that everytime
I install a new major version of ECL, I have to wipe out the previous version
first -- go figure out why.  On windows, I cannot use it to build OpenAxiom
executable because the ecl.dll is not found when the program produced
by build-program is launched.

-- Gaby

Hi Juanjo!

On Sat, 30 Aug 2008 09:19:19 +0200, Juan Jose Garcia-Ripoll wrote:
> On Sat, Aug 30, 2008 at 1:07 AM, Luca Capello <luca@...> wrote:
>> This bug has nothing to do with the rpath issue (now solved [1]).
>> Thus, the problem remains: is there any particular reason for
>> /usr/lib/libecl.so not providing a SONAME?
>
> That is not something ECL has to provide. It is more a configuration
> option that operating systems may provide.

Sorry, I'm not a skilled programmed, but I don't understand why this is
not ECL task: ECL provides the libecl.so library, so who else should
provide its SONAME?

> You have to consider the following: with every binary release we are
> adding more functions and the names of old ones change. That means
> being a rapidly evolving project we are definitely going to break
> binary compatibility very frequently.

Isn't this the reason for SONAME existence?  At least this is how I see
it and it seems that others share my view [1][2].

> I should rather say with every release.

This means that you need to update the SONAME for every release.  And I
don't see this as a stopper.

> Furthermore, ECL is currently not being used as a library by any
> project. It is only either a runtime for compiled files or the
> interpreted environment itself.

However a standalone program [3] works out of the box with just
libecl.so, doesn't it?  This means that while ecl (the executable) is
not used as a library, libecl.so acts like a *real* library (as Gabriel
Dos Reis already pointed out [4]).  Thus, without a SONAME and from a
simple `ldd` output, there's no way to know which ECL versions the
program was built with.

> Do you expect SBCL to use some kind of SONAME for its core? Not
> really.

SBCL doesn't provide any library which can be used *without* its core
(thus they are installed into /usr/lib/sbcl/, the same being true for
e.g. CLISP).  Similarly, the ECL "libraries" needed for the core reside
in /usr/lib/ecl/ and don't need any SONAME.

In the next days I'll upload a new Debian version for ECL to solve bug
#495756 [5] in time for the lenny release [6].  I'd like to solve this
issue as well, is it possible?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://mail-index.netbsd.org/tech-toolchain/1998/07/17/0000.html
[2] http://wiki.linuxquestions.org/wiki/Library-related_Commands_and_Files#soname
    NB, not that I blindly trust random wikis...
[3] New manual: "1.6.3. Example of standalone program"
[4] Message-ID: <206fcf960808300836h69a9ecc5heaba09277f08b84e@...>
[5] http://bugs.debian.org/495756
[6] http://wiki.debian.org/DebianLenny

On Wed, Sep 3, 2008 at 4:12 PM, Luca Capello <luca@...> wrote:
>> That is not something ECL has to provide. It is more a configuration
>> option that operating systems may provide.
>
> Sorry, I'm not a skilled programmed, but I don't understand why this is
> not ECL task: ECL provides the libecl.so library, so who else should
> provide its SONAME?

The SONAME is a basically a linker option and can be passed to ECL as
a configuration flag during the build process. It is not our task as
developers of ECL to impose a certain numbering scheme or link flags
on the main source distribution, but rather the package maintainer to
set it based on their own criteria or distribution standards. At least
this is how I have seen that done for other packages, including
Debian's ones (http://packages.debian.org/etch/libgc1c2) and that is
what I meant by the text above.

Juanjo

-- 
Instituto de Física Fundamental
CSIC, Serrano, 113, Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

Hi Juanjo!

On Wed, 03 Sep 2008 17:41:25 +0200, Juan Jose Garcia-Ripoll wrote:
> On Wed, Sep 3, 2008 at 4:12 PM, Luca Capello <luca@...> wrote:
>>> That is not something ECL has to provide. It is more a configuration
>>> option that operating systems may provide.
>>
>> Sorry, I'm not a skilled programmed, but I don't understand why this is
>> not ECL task: ECL provides the libecl.so library, so who else should
>> provide its SONAME?
>
> The SONAME is a basically a linker option and can be passed to ECL as
> a configuration flag during the build process. It is not our task as
> developers of ECL to impose a certain numbering scheme or link flags
> on the main source distribution, but rather the package maintainer to
> set it based on their own criteria or distribution standards.

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.

I consider this as the last solution and if I'm really forced to
implement it, the ECL SONAME in Debian will reflect the upstream
version.

> At least this is how I have seen that done for other packages,
> including Debian's ones (http://packages.debian.org/etch/libgc1c2) and
> that is what I meant by the text above.

The libgc1c2 package in etch already uses upstream SONAME [3]:

--8<---------------cut here---------------start------------->8---
libgc (1:6.2+6.3alpha1-1) unstable; urgency=low

  * New upstream release (closes: #197031)
  * Switch to using upstream's autoconf (and therefore upstream's sonames, so
    rename packages to match the sonames)  (closes: #178869)
  * Relibtoolize.

 -- Ryan Murray <rmurray@...>  Mon, 11 Aug 2003 15:57:57 -0700
--8<---------------cut here---------------end--------------->8---

Thx, bye,
Gismo / Luca

Footnotes: 
[1] and yes, I compared Debian and Ubuntu *in purpose*, since while the
    latter syncs with Debian before every freeze, in some areas they
    diverge quite a lot
[2] http://www.linuxfoundation.org/en/LSB
[3] http://packages.debian.org/changelogs/pool/main/libg/libgc/libgc_6.8-1/changelog

On Sat, Sep 6, 2008 at 2:28 PM, Luca Capello <luca@...> wrote:
> Hi Juanjo!
>
> On Wed, 03 Sep 2008 17:41:25 +0200, Juan Jose Garcia-Ripoll wrote:
>> On Wed, Sep 3, 2008 at 4:12 PM, Luca Capello <luca@...> wrote:
>>>> That is not something ECL has to provide. It is more a configuration
>>>> option that operating systems may provide.
>>>
>>> Sorry, I'm not a skilled programmed, but I don't understand why this is
>>> not ECL task: ECL provides the libecl.so library, so who else should
>>> provide its SONAME?
>>
>> The SONAME is a basically a linker option and can be passed to ECL as
>> a configuration flag during the build process. It is not our task as
>> developers of ECL to impose a certain numbering scheme or link flags
>> on the main source distribution, but rather the package maintainer to
>> set it based on their own criteria or distribution standards.
>
> 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.

-- Gaby

On Sun, Sep 7, 2008 at 2:18 AM, Gabriel Dos Reis <
gdr@...> 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

Last change in CVS ( 2008/09/09 )

 - We switch to an Ubuntu-like versioning system, based on
$(year).$(month).x
   where "x" is 0 for a release or any higher number for a patched version.

 - In Unix-type systems, ECL now installs with a "soname" and using
versioned
   directory names, such as /usr/lib/ecl-8.9.0, /usr/lib/libecl.so.8.9, etc

This should be more than enough.

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

On Tue, Sep 9, 2008 at 9:40 PM, Luca Capello <luca@...> wrote:

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


That is too large and the shorter version can be directly used in sonames

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.


This is true.


> Could this improve the situation?


As I said, the problems are not on our side, so I presume this question goes
to the bug originator  :-)


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


As mentioned in the previous email / bug answer, this change has been
committed to ECL already.

Juanjo

-- 
Instituto de Física Fundamental
CSIC, Serrano, 113, Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

On Tue, Sep 9, 2008 at 11:15 PM, Luca Capello <luca@...> wrote:

> On Tue, 09 Sep 2008 21:38:13 +0200, Juan Jose Garcia-Ripoll wrote:
> > Last change in CVS ( 2008/09/09 )
> >
> >  - We switch to an Ubuntu-like versioning system, based on
> $(year).$(month).x
> >    where "x" is 0 for a release or any higher number for a patched
> version.
>
> 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. It means I reserve the
possibility to have minor bugs fixed and leave that to that last number.
However, you will not see that I use something != *.*.0 in a release. 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.

>
> >  - In Unix-type systems, ECL now installs with a "soname" and using
> versioned
> >    directory names, such as /usr/lib/ecl-8.9.0, /usr/lib/libecl.so.8.9,
> etc
>
> 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.



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

Juanjo

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

On Wed, Sep 10, 2008 at 12:27 AM, Luca Capello <luca@...> wrote:

> I prefer to keep the ECL situation as it is now: Debian ships only one
> version, which is the latest release [1].


Luca, I think you are thinking too way ahead. Currently, there is no Debian
program that depends on an specific version of ECL, so why would you add
packages for all preceding versions? I think it only makes sense when the
Debian repository itself has programs that depend on precise versions of a
library. Besides that, if a person needs a very particular version of ECL
for his / her program to run, with the current soname system he can keep
that version installed.

Juanjo

-- 
Instituto de Física Fundamental
CSIC, Serrano, 113, Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

On Tue, Sep 9, 2008 at 2:38 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll@...> wrote:
> Last change in CVS ( 2008/09/09 )
>
>  - We switch to an Ubuntu-like versioning system, based on
> $(year).$(month).x
>    where "x" is 0 for a release or any higher number for a patched version.
>
>  - In Unix-type systems, ECL now installs with a "soname" and using
> versioned
>    directory names, such as /usr/lib/ecl-8.9.0, /usr/lib/libecl.so.8.9, etc

Fantastic!  Thanks,

-- Gaby