On Tue, 26 Oct 1999, Stephen J Baker wrote:
> Well, if that's what the LSB standard requires then:
>
> 1) It's a damned stupid standard and we should ignore it.
You may choose to do so.
> 2) There are no other libraries on either of the Linux boxes that
> I use that conform to this so-called standard. (One of those machines
> is a RedHat 5.2 box and the other is a bang up to date SuSE 6.1).
> There is no /usr/lib/LSB directory on either machine.
Neither of these releases implement the LSB. In fact, no release implements
it yet. If you'll take a quick look at the website (http://www.linuxbase.org/)
you'll see that it is at verion 0.1.
We are still at the point of finding all of the dumb things that people have
done in libraries that tend to break applications.
> Having to run the BINARY of your application through some kind of 'mklsb'
> kludge for every library you link to (if they all conformed to the standard)
> would get out of hand - fast!
You run mklsb on your application once after it is linked. It doesn't matter
how many of the LSB defined libraries you've used. The LSB only defines a
fixed set of libraries, and mklsb will know about all of them.
> Having to have two copies of every library (one for the stubs and
> another for the code) is just asking for trouble too.
The stubs library will be generated from a list list of interfaces, and won't
be changing often. Getting the two out of sync shouldn't be a problem in that
area.
> I suggest we ignore this LSB thingy and do what every other Linux
> library currently does. This would mean:
>
> /usr/lib/libGL.so.1.2.<revision>
>
> ...with a symlink from:
>
> /usr/lib/libGL.so.1.2
> and
> /usr/lib/libGL.so
You are certainly free to do this. The LSB doesn't prevent you from doing
anything outside of the spec as long as it doesn't conflict with the spec.
> I have recently been talking with one of the Debian package maintainers
> (the guy who is responsible for putting my PLIB libraries into the
> next Debian release)...he tells me that Debian is committed to
> 'Doing Things Right' - and the 'Right' place for my libraries turns
> out to be with the usual '/usr/lib/lib<name>.so.<major>.<minor>' naming
> convention.
A bit of history. Initially, the LSB was going to just specify a set of
libraries, and their version. This did not go over very well because the
distributions realized that they could then no longer upgrade components
whenever they wanted to. This is why the LSB is based on a behavioral
description, instead of a feature/version list.
> I was really hoping that the standard we were drawing up for OpenGL
> under Linux would make my life as a maintainer of Linux/OpenGL
> software easier. I currently get about 80 emails a week from
> people who have trouble installing my freeware game - easily 90%
> of those are because they don't have OpenGL installed properly.
>
> We need to make this EASIER - and if some standard (that nobody
> else follows) makes it HARDER - then we are doing nobody any
> favors.
The results of this group can be published independantly of the LSB. We
don't want to get in anyones way of making progress. If the results are
well written, thorough and testable, then the LSB will also adopt it. You
can use what ever library naming scheme you want to use. The LSB will use
the LSB format when it includes GL in the LSB. It just adds one more thing
for each distribution to do to provide a LSB environment.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Metro Link Incorporated South Carolina Office
4711 North Powerline Road 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.938.0283 voice: 803.951.3630
fax: 954.938.1982 SkyTel: 800.405.3401
http://www.metrolink.com/
