Debian Bug report logs - #503314
liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Soeren Sonnenburg <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Fri, 24 Oct 2008 18:47:32 +0200

Package: lp-solve
Version: 5.5.0.10-10
Severity: normal

The library should really be in /usr/lib like liblpsolve55*.a is.

-- System Information:
Debian Release: lenny/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.27-rc9-sonne (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lp-solve depends on:
ii  libc6                         2.7-15     GNU C Library: Shared libraries
ii  libsuitesparse-3.1.0          3.1.0-3    collection of libraries for comput

lp-solve recommends no packages.

lp-solve suggests no packages.

-- no debconf information

Message #10 received at [email protected] (full text, mbox, reply):

From: Rene Engelhard <[email protected]>

To: Soeren Sonnenburg <[email protected]>, [email protected]

Cc: [email protected]

Subject: Re: Bug#503314: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Tue, 2 Dec 2008 10:56:22 +0100

severity 503314 wishlist
tag 503314 + wontfix
thanks

Hi,

Soeren Sonnenburg wrote:
> The library should really be in /usr/lib like liblpsolve55*.a is.

No, definitely not. Doing so would be a RC bug.

*Unversioned* library. With NO SONAME. API/ABI changes from 5.5.0.10 to
5.5.0.13.

No way. There's a reason it's in its private dir.

Regards,

Rene

Message #19 received at [email protected] (full text, mbox, reply):

From: Soeren Sonnenburg <[email protected]>

To: Rene Engelhard <[email protected]>

Cc: [email protected]

Subject: Re: Bug#503314: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Tue, 02 Dec 2008 15:21:58 +0100

On Tue, 2008-12-02 at 10:56 +0100, Rene Engelhard wrote:
> severity 503314 wishlist
> tag 503314 + wontfix
> thanks
> 
> Hi,

Hi Rene,

> Soeren Sonnenburg wrote:
> > The library should really be in /usr/lib like liblpsolve55*.a is.
> 
> No, definitely not. Doing so would be a RC bug.

Sorry, but there seems to be some misunderstanding. As this library
obviously has no proper soname, the right fix is to suffix the library
with -<version>. This is how it is written in the policy/debian library
packaging guidelines.

> *Unversioned* library. With NO SONAME. API/ABI changes from 5.5.0.10 to
> 5.5.0.13.

yes then that is why you would need to introduce a new package
liblpsolve-5.5.0.13.

> No way. There's a reason it's in its private dir.

This does not help. When a project requires liblpsolve it still cannot
use it (as abi changes are not dealt with). So you could as well remove
the .so file an integrate liblpsolve statically.

Soeren

Message #24 received at [email protected] (full text, mbox, reply):

From: Rene Engelhard <[email protected]>

To: Soeren Sonnenburg <[email protected]>

Cc: [email protected]

Subject: Re: Bug#503314: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Tue, 2 Dec 2008 15:45:42 +0100

Hi,

Soeren Sonnenburg wrote:
> > No, definitely not. Doing so would be a RC bug.
> 
> Sorry, but there seems to be some misunderstanding. As this library
> obviously has no proper soname, the right fix is to suffix the library
> with -<version>. This is how it is written in the policy/debian library
> packaging guidelines.

Where? libpkg-guide?
(It contains many bad suggestions you get hit with if you do it that way)

> > *Unversioned* library. With NO SONAME. API/ABI changes from 5.5.0.10 to
> > 5.5.0.13.
> 
> yes then that is why you would need to introduce a new package
> liblpsolve-5.5.0.13.

Which would change package name on every version :/. Even when ABI/API
did *not* change and as such a rename would not be necessary nor useful.

I don't think the RMs will want to have one transition where Fortran stuff,
OOo etc. will wait for such a package rename....

> > No way. There's a reason it's in its private dir.
> 
> This does not help. When a project requires liblpsolve it still cannot
> use it (as abi changes are not dealt with). So you could as well remove

ABI changes are not relevant, as you per default link with the static .a
(because the .so is not found unless you tell it the dir using -L)

Only if you know what you do you should link against the shared
liblpsolve55.so

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [email protected] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73

Message #29 received at [email protected] (full text, mbox, reply):

From: Rene Engelhard <[email protected]>

To: Soeren Sonnenburg <[email protected]>, [email protected]

Subject: Re: Bug#503314: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Tue, 2 Dec 2008 16:55:20 +0100

Hi again,

Rene Engelhard wrote:
> I don't think the RMs will want to have one transition where Fortran stuff,
> OOo etc. will wait for such a package rename....

We already had that "fun", fwiw, you can ask -release :-)

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [email protected] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73

Message #34 received at [email protected] (full text, mbox, reply):

From: Rene Engelhard <[email protected]>

To: Soeren Sonnenburg <[email protected]>, [email protected]

Subject: Re: Bug#503314: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Tue, 2 Dec 2008 17:43:36 +0100

Hi,

Soeren Sonnenburg wrote:
> On Tue, 2008-12-02 at 16:55 +0100, Rene Engelhard wrote:
> > Hi again,
> > 
> > Rene Engelhard wrote:
> > > I don't think the RMs will want to have one transition where Fortran stuff,
> > > OOo etc. will wait for such a package rename....
> > 
> > We already had that "fun", fwiw, you can ask -release :-)
> 
> Heh, I recognize that oo-calc depends on lp-solve (maybe it shouldn't
> and instead use glpk?).

That's not in my hands. Kohei used liblpsolve for his Solver and Sun
does that too after they refused to take Koheis.

> Anyway, if no one can rely on the .so I don't see a reason why the .so

openoffice.org-calc does ;-)

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [email protected] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73

Message #39 received at [email protected] (full text, mbox, reply):

From: Soeren Sonnenburg <[email protected]>

To: 503314 <[email protected]>

Subject: Re: Bug#503314: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Tue, 02 Dec 2008 17:48:58 +0100

On Tue, 2008-12-02 at 16:55 +0100, Rene Engelhard wrote:
> Hi again,
> 
> Rene Engelhard wrote:
> > I don't think the RMs will want to have one transition where Fortran stuff,
> > OOo etc. will wait for such a package rename....
> 
> We already had that "fun", fwiw, you can ask -release :-)

Heh, I recognize that oo-calc depends on lp-solve (maybe it shouldn't
and instead use glpk?).

Anyway, if no one can rely on the .so I don't see a reason why the .so
file is shipped at all and not just the .a (and lp-solve being
statically linked to it).

Soeren.

Message #44 received at [email protected] (full text, mbox, reply):

From: Soeren Sonnenburg <[email protected]>

To: Rene Engelhard <[email protected]>

Cc: [email protected]

Subject: Re: Bug#503314: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Tue, 02 Dec 2008 17:56:52 +0100

On Tue, 2008-12-02 at 17:43 +0100, Rene Engelhard wrote:
> Hi,
> 
> Soeren Sonnenburg wrote:
> > On Tue, 2008-12-02 at 16:55 +0100, Rene Engelhard wrote:
> > > Hi again,
> > > 
> > > Rene Engelhard wrote:
> > > > I don't think the RMs will want to have one transition where Fortran stuff,
> > > > OOo etc. will wait for such a package rename....
> > > 
> > > We already had that "fun", fwiw, you can ask -release :-)
> > 
> > Heh, I recognize that oo-calc depends on lp-solve (maybe it shouldn't
> > and instead use glpk?).
> 
> That's not in my hands. Kohei used liblpsolve for his Solver and Sun
> does that too after they refused to take Koheis.

well rather off topic, but IMHO ``best'' linear open source solver is
clp, followed by glpk followed by maybe lpsolve.

> > Anyway, if no one can rely on the .so I don't see a reason why the .so
> 
> openoffice.org-calc does ;-)

Argh, but then I don't understand how openoffice.org-calc uses a clean
upgrade path. I mean it depends on lp-solve (>= 5.5.0.10-10) so if
future versions of liblpsolve55.so break api/abi it will just crash...

I am asking as I am searching for a way to do the same with shogun.

Soeren

Message #49 received at [email protected] (full text, mbox, reply):

From: Rene Engelhard <[email protected]>

To: Soeren Sonnenburg <[email protected]>

Cc: [email protected]

Subject: Re: Bug#503314: liblpsolve55.so is in /usr/lib/lp_solve not /usr/lib

Date: Tue, 2 Dec 2008 18:03:36 +0100

Hi,

Soeren Sonnenburg wrote:
> Argh, but then I don't understand how openoffice.org-calc uses a clean
> upgrade path. I mean it depends on lp-solve (>= 5.5.0.10-10) so if
> future versions of liblpsolve55.so break api/abi it will just crash...

Well, I (co-)maintain both, so I can add Depends: to openoffice.org
and Conflicts (or maybe Breaks:) to lp-solve as appropriate ;-)

Of course that's not the ideal way, but... :)

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [email protected] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73

Send a report that this bug log contains spam.