Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Greenland]

On 29-Jul-05, 08:50 (CDT), GOMBAS Gabor <[EMAIL PROTECTED]> wrote: 
> On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
> Exercise: let's say I have an application that uses GSSAPI, and has to
> be able to be built statically. Requirements:
> 
> - It should build with Heimdal's libgssapi
> - It should build with MIT's libgssapi
> - It should build with Globus GSI
> 
> All these cases require a completely different set of dependant static
> libraries even though I'm only using the GSSAPI interface.
> 
> With libtool, it's trivial, since all the information you need is
> already expressed in the .la files.

Unless they're borked, which seems to happen frequently.

> Care to explain a method that is
> 
> - better than libtool
> - works already (the most important requirement being that Globus must
>   support it out-of-the-box)
> - not Debian-specific (only a minor set of the target machines runs
>   Debian)?

Makefile conditionals. Work on all platforms that support GNU make (i.e.
pretty much any of current interest), explicit, trivial to debug and
update.

Of course, it requires you to actually *understand* what your software
dependencies are, but I don't see that as a bad thing.

> Well, I have used libtool on a couple of architectures and my opinion is
> that using libtool is still way more effective than re-inventing it over
> and over again. Yes, it has bugs (for example the AIX support is
> notoriously buggy), but they can be fixed just like any other software.

But apparently never are. Mostly because libtool is a horrendous,
incomprehensilbe shell script. And since AIX is one of our major
platforms, I spend *way* too much time fighting with it.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Langasek]

On Thu, Jul 28, 2005 at 02:18:29PM -0400, Jay Berkenbilt wrote:
> > FWIW, detecting a fixed libtool would be rather difficult, since it's the
> > libtool used by the depending application which does the recursion and
> > therefore needs to be fixed.

> I was thinking we'd be able to tell from the .la file what we needed
> to do.  If a new libtool still generated a .la file, perhaps it could
> put some kind of version indicator or something similar.

Yeah, that still doesn't do any good (and yes, libtool would still need to
generate .la files, or else it's no longer serving its purpose), because
upstream isn't going to stand for breaking backwards compatibility, and
that's the only way you could have any control at all over the version of
libtool that an application was trying to use when building -- and that's
not really more control than you also have just by dropping the -dev
dependencies and letting the applications fend for themselves.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Brian May]

> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:

>> fact 3: libtool library libtool tries to implement a wrapper
>> around shared library and static library, so that both of them
>> can be uniformly processed, and allows specifying just: libtool
>> cc -lnewt a.c

Steve> Why is this better?

Because it means your application you are linking does not need to
know the implementation details behind libnewt, or what libraries this
particular version of libnewt happens to require. This might not be a
sane example, but consider if the maintainer of libnewt suddenly
recompiled new versions of the package to depend on libssl for
example, this might result in all applications that use libnewt
statically unable to build, because the list of libraries is hard
coded.

This example is simple, for a more complicated example, see the
Heimdal libraries...

This may be important if you require a static version for any reason
or your platform doesn't support interdependencies between shared
libraries. I think there is at least one OS without good support for
shared libraries - what was its name again? - not very common - I
think its called "MS-Windows".
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[GOMBAS Gabor]

On Fri, Jul 29, 2005 at 12:06:38PM -0400, Jay Berkenbilt wrote:

> This is nice, but I think it's not really very autoconfish [tm] in
> spirit.

It is not meant to be autoconfish. It is meant to be run _before_
configure, so you can decide if you have to re-libtoolize the package or
not.

> Also, this invokes autoconf,
> which we don't necessarily want to do at package build time since this
> will cause packages to require a build dependency on autotools, a
> topic which has been discussed at length before.

I think I know what you miss: you think about checking the version of
the _installed_ libtool package. But that is completely uninteresting as
it will _not_ be used during the build. You want to know the libtool
version that was used for _generating_ the source package (or upstream
tarball). And if that version is wrong, then you have to re-run
libtoolize and autoconf anyway, so you do need to have autotools
installed.

If you do not want to build-depend on autotools then it is too late to
check the libtool version at build time (well, you can still check it
and generate an explicit FTBFS if it is wrong so forgetting to
re-libtoolize the package will be detected more easily).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Jay Berkenbilt]

GOMBAS Gabor <[EMAIL PROTECTED]> wrote:

> On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
>
>> I'd think we could come up with a way to detect the version of libtool
>> in use, somehow. :)
>
> LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
> LTMAIN_SH_PATH="${LTMAIN_SH_PATH:-.}"
> grep ^VERSION "$LTMAIN_SH_PATH"/ltmain.sh | cut -d= -f2

This is nice, but I think it's not really very autoconfish [tm] in
spirit.  Perhaps it would be better to be able to detect whether the
desired feature (whatever that is) is present in the appropriate
libtool rather than looking at the version number.  I had indicated in
an earlier post that maybe looking at .la files would be possible,
though this is by no means a certainty.  Also, this invokes autoconf,
which we don't necessarily want to do at package build time since this
will cause packages to require a build dependency on autotools, a
topic which has been discussed at length before.  If we went the route
of detecting libtool version, I believe we would need to know the
version of libtool that was used to create the .la file of the
dependent package.  Is this right?  Maybe not -- I'm not fully up to
speed on all the issues yet.  Anyway, I'll put together a more
comprehensive proposal on how dh_libtool should work when I have a
chance to work on it.  (Unfortunately, that's not going to be for a
few weeks -- things are even more unusually busy than their usual
level of unusualness right now in both my personal and professional
lives...)  Of course, all ideas and suggestions such as this are
welcome and are being saved in my notes, in spite of any first
impressions I may have on whether they will actually work
specifically.  Thanks. :-)

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[GOMBAS Gabor]

On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:

> I'd think we could come up with a way to detect the version of libtool
> in use, somehow. :)

LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
LTMAIN_SH_PATH="${LTMAIN_SH_PATH:-.}"
grep ^VERSION "$LTMAIN_SH_PATH"/ltmain.sh | cut -d= -f2

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[GOMBAS Gabor]

On Thu, Jul 28, 2005 at 07:05:34AM -0400, Stephen Frost wrote:

> We've had that discussion before.  Last I recall there wasn't really a
> huge fight to keep them.

Well, Debian developers do not really need them. But there are people
who do not develop Debian but develop other software _using_ Debian and
static linking is important for them (for example, if you have to submit
a job to a remote machine where you have no knowledge nor control over
what software is installed, you have no other choice than to link
everything (except maybe libc) statically into your application).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[GOMBAS Gabor]

On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:

> Why is this better? I have to change my perfectly normal, standard Unix
> link command to use something that completely hides the actual link
> command and makes debugging problems nearly impossible?

Exercise: let's say I have an application that uses GSSAPI, and has to
be able to be built statically. Requirements:

- It should build with Heimdal's libgssapi
- It should build with MIT's libgssapi
- It should build with Globus GSI

All these cases require a completely different set of dependant static
libraries even though I'm only using the GSSAPI interface.

With libtool, it's trivial, since all the information you need is
already expressed in the .la files. Care to explain a method that is

- better than libtool
- works already (the most important requirement being that Globus must
  support it out-of-the-box)
- not Debian-specific (only a minor set of the target machines runs
  Debian)?

> I really don't get it. And, for the record, the company I work for
> ships code for a variety of Unices. I spend a *lot* more of my time
> debugging libtool brokenness (not to mention auto* brokeness) than I
> do tracking down which libraries need which other libraries. So when I
> say "I don't get it", it's not lack of experience with the tools, I'm
> just completely mystified why people think that libtool is an
> *improvement*.

Well, I have used libtool on a couple of architectures and my opinion is
that using libtool is still way more effective than re-inventing it over
and over again. Yes, it has bugs (for example the AIX support is
notoriously buggy), but they can be fixed just like any other software.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> I think static libs have outlived their usefulness in Debian for the
> most part; but using this to justify creating whole *new* packages for
> static linking would just be insane.  The dependencies of -dev packages
> are just not that big a deal to warrant having to manage all of these
> new binary packages.

Fully statically linked binaries (including a static libc) are not
particularly useful these days, nor is statically linking *within* Debian
in official packages.  However, statically linking is still rather useful
for Debian *users* from time to time.

For example, I occasionally build binaries that use the Kerberos libraries
and explicitly link just the Kerberos libraries (but not libc) static,
since the binaries are then easily portable to any other Linux
distribution without having to worry about whether the right libraries are
installed.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Langasek]

On Fri, Jul 29, 2005 at 07:06:34AM +0900, Junichi Uekawa wrote:
> > > - Don't ship .la files in the -dev package; don't depend on any other -dev
> > >   packages except those whose headers you need.  This gives optimal 
> > > results
> > >   for shared linking by pruning all unnecessary build-dependencies and
> > >   dependencies; but it also screws over anyone trying to do static 
> > > linking,
> > >   who now has to go *recursively* hunt down the package name for each of 
> > > the
> > >   library dependencies, based only on the names of the symbols exported.
> > >   (So why would anyone ship the static libs at this point...?)

> > If we want to support static linking then let's break it off into it's
> > own '-static' package with appropriate dependencies.  Personally I don't
> > think it's really worth it and we should just go ahead and drop the
> > static libraries too.  It'd certainly make the -dev packages alot
> > smaller.  Maybe then we could just put -dbg stuff in the -dev packages.
> > :)

> That's the portion which was missing in your argument,
> resulting in your failure to convey information.

> You need to state 'drop static lib linking support from -dev package'  
> rather than 'libtool is broken'.

> libtool isn't really broken; it's just that static libs and shared libs
> behave differently.

No, libtool is moderately broken, as Stephen has pointed out -- it insists
on having dependent .la files present on the system when doing dynamic
linking, even though they shouldn't be needed.

> > > - Kill the .la files and .a files.  Drop support for static linking.  Not
> > >   something that should be done lightly and without prior project-wide
> > >   discussion.

> > We've had that discussion before.  Last I recall there wasn't really a
> > huge fight to keep them.

> Current situation is that we have removed the mandate from
> policy to require static libs, since some libs really don't work
> with static linking.

> However, it is still in policy 8.3. that if it exists, it will be 
> in -dev package.

> Having an extra -static package is rather drastic change,
> and I personally still do like the ability of being able to 
> do static linking.

I think static libs have outlived their usefulness in Debian for the most
part; but using this to justify creating whole *new* packages for static
linking would just be insane.  The dependencies of -dev packages are just
not that big a deal to warrant having to manage all of these new binary
packages.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> > - Don't ship .la files in the -dev package; don't depend on any other -dev
> >   packages except those whose headers you need.  This gives optimal results
> >   for shared linking by pruning all unnecessary build-dependencies and
> >   dependencies; but it also screws over anyone trying to do static linking,
> >   who now has to go *recursively* hunt down the package name for each of the
> >   library dependencies, based only on the names of the symbols exported.
> >   (So why would anyone ship the static libs at this point...?)
> 
> If we want to support static linking then let's break it off into it's
> own '-static' package with appropriate dependencies.  Personally I don't
> think it's really worth it and we should just go ahead and drop the
> static libraries too.  It'd certainly make the -dev packages alot
> smaller.  Maybe then we could just put -dbg stuff in the -dev packages.
> :)

That's the portion which was missing in your argument,
resulting in your failure to convey information.

You need to state 'drop static lib linking support from -dev package'  
rather than 'libtool is broken'.

libtool isn't really broken; it's just that static libs and shared libs
behave differently.


> > - Kill the .la files and .a files.  Drop support for static linking.  Not
> >   something that should be done lightly and without prior project-wide
> >   discussion.
> 
> We've had that discussion before.  Last I recall there wasn't really a
> huge fight to keep them.

Current situation is that we have removed the mandate from
policy to require static libs, since some libs really don't work
with static linking.

However, it is still in policy 8.3. that if it exists, it will be 
in -dev package.

Having an extra -static package is rather drastic change,
and I personally still do like the ability of being able to 
do static linking.


regards,
junichi

-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Jay Berkenbilt]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> It doesn't exist; I think it's a great idea.  Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?

Sounds good to me.

I'm going to be leaving my current job in a few weeks and taking
several weeks off between jobs.  I'll try to work on it then along
with some other debian tasks that I've been putting off.  I can't
imagine it would be very difficult.

> FWIW, detecting a fixed libtool would be rather difficult, since it's the
> libtool used by the depending application which does the recursion and
> therefore needs to be fixed.

I was thinking we'd be able to tell from the .la file what we needed
to do.  If a new libtool still generated a .la file, perhaps it could
put some kind of version indicator or something similar.  Anyway, it's
not clear to me what a fixed libtool would do differently (I don't
know libtool that well) though.  Anyway, I've been looking for an
excuse to dig into this.  Once I could clearly articulate why libtool
is broken and what a non-broken libtool would look like, it will be
much clearer what kind of strategy would work in both cases.

--Jay

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Greenland]

On 28-Jul-05, 03:02 (CDT), Junichi Uekawa <[EMAIL PROTECTED]> wrote: 
> fact 1: shared library 
> 
>   gcc -lnewt a.c

Right. No problem.

> fact 2: static library
> 
>   gcc -lslang -lnewt a.c

Right, Just like it's always been on Unix systems.

> fact 3: libtool library
> libtool tries to implement a wrapper around shared library and 
> static library, so that both of them can be uniformly processed,
> and allows specifying just:
>   libtool cc -lnewt a.c

Why is this better? I have to change my perfectly normal, standard Unix
link command to use something that completely hides the actual link
command and makes debugging problems nearly impossible? I really don't
get it. And, for the record, the company I work for ships code for a
variety of Unices. I spend a *lot* more of my time debugging libtool
brokenness (not to mention auto* brokeness) than I do tracking down
which libraries need which other libraries. So when I say "I don't get
it", it's not lack of experience with the tools, I'm just completely
mystified why people think that libtool is an *improvement*.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Stephen Frost]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> It doesn't exist; I think it's a great idea.  Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?

This sounds reasonable to me; I appriciate that it's a libtool-specific
thing and not a blanket policy. :)

> FWIW, detecting a fixed libtool would be rather difficult, since it's the
> libtool used by the depending application which does the recursion and
> therefore needs to be fixed.

I'd think we could come up with a way to detect the version of libtool
in use, somehow. :)  Could always have the tool accept a command-line
option to force it one way or the other.  Then we could run around and
file bugs to use the tool, and then bugs to upgrade libtool. :)

Stephen


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Langasek]

On Thu, Jul 28, 2005 at 08:29:52AM -0400, Jay Berkenbilt wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:

> > - Leave the .la files in place; -dev packages need to depend on -dev
> >   packages corresponding to those runtime dependencies that are also built
> >   using libtool.  This is the status quo.

> If we do this (which I think we should for now), I would suggest that
> we have a debhelper script analogous to dh_shlibdeps that parses .la
> files to automatically generate -dev build dependencies, and that this
> should also be fixed if libtool is fixed (and should detect whether it
> is using a fixed libtool).  Then maintainers of libraries that use
> libtool will automatically get the -dev dependencies required to
> satisfy issues with libtool now, and if/when libtool is fixed, those
> dependencies can disappear automatically without having to have all
> the maintainers go through a lot of trouble twice.

> My suggestion doesn't solve the problem, but it does make it easier to
> deal with.  Maybe this already exists and I'm just not aware of it.
> I've been thinking about writing this for a while since I maintain
> several libraries that use libtool and have made the mistake of
> forgetting a -dev dependency before.

It doesn't exist; I think it's a great idea.  Perhaps a tool named
dh_libtool, which populates a substvar named ${libtool:Depends}?

FWIW, detecting a fixed libtool would be rather difficult, since it's the
libtool used by the depending application which does the recursion and
therefore needs to be fixed.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Jay Berkenbilt]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> - Leave the .la files in place; -dev packages need to depend on -dev
>   packages corresponding to those runtime dependencies that are also built
>   using libtool.  This is the status quo.

If we do this (which I think we should for now), I would suggest that
we have a debhelper script analogous to dh_shlibdeps that parses .la
files to automatically generate -dev build dependencies, and that this
should also be fixed if libtool is fixed (and should detect whether it
is using a fixed libtool).  Then maintainers of libraries that use
libtool will automatically get the -dev dependencies required to
satisfy issues with libtool now, and if/when libtool is fixed, those
dependencies can disappear automatically without having to have all
the maintainers go through a lot of trouble twice.

My suggestion doesn't solve the problem, but it does make it easier to
deal with.  Maybe this already exists and I'm just not aware of it.
I've been thinking about writing this for a while since I maintain
several libraries that use libtool and have made the mistake of
forgetting a -dev dependency before.

--Jay


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > - Option 4 (requires volunteers): fix libtool
> 
> Blankly stating that libtool needs to be 'fixed'
> because it is 'broken' is not very helpful.
> Would you care to explain what needs to be fixed and why 
> it is broken?  Good working examples would be good.

One of the issues associated with just dropped .la files was that
libtool apparently doesn't handle having a .la file go missing in the
middle of a dependency chain.

ie: libfoo is built against libbar, both using libtool and both having
.la files.  libbar's .la file is then removed.  If you try to build
libxyz against libfoo, libtool will break because libfoo's .la says
libbar should have a .la but it doesn't.

Making libtool handle the missing .la file case for shared linking (at
least) would drop the requirement that -dev packages depend on -dev
packages when building shared libraries.  On Debian, at least, the .la
files generally shouldn't be necessary unless you're doing static
building.  Even then I don't think they're actually necessary until you
get up to the application that you want to build statically.  That is to
say, you shouldn't need them to build a static version of your library
unless you also build into that .a all the other libraries your library
depends on, and that's certainly not something we'd want to do.

> The following are background informations, please do comment
> if you find something is wrong about these:
> 
> libnewt is an example library that requires libslang.
> The names are just symbollic; they just represent
> random library.
> 
> fact 1: shared library 
> 
>   gcc -lnewt a.c
> should work, since slang dependency is declared in NEEDED field
> of libnewt.so, which the link will be resolved at run-time.
> 
> fact 2: static library
> 
>   gcc -lslang -lnewt a.c
> is required for static lib linking, since .a files do not have
> dependency information, and symbols need to be resolved at link time.
> 
> 
> fact 3: libtool library
> libtool tries to implement a wrapper around shared library and 
> static library, so that both of them can be uniformly processed,
> and allows specifying just:
>   libtool cc -lnewt a.c
> 
> (implementation detail: .la files contain the dependency 
> information for .a).

The issue here is that libtool doesn't need the .la files when doing
shared linking, but it breaks if it's not there when another .la file
said it should be.

> Debian implementation:
> 
> Packages Build-Depend on -dev packages they directly require,
> thus a package requiring newt will Build-Depend on libnewt-dev,
> but not libslang2-dev.
> 
> libnewt-dev will need to Depend on libslang2-dev, or
> static lib compilation with libtool will break.

This isn't actually the problem, if only static lib compilation broke I
don't think people would actually care all that much.  The problem is
that *shared* library compilation with libtool breaks, which is a
problem with libtool.

Stephen


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Stephen Frost]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> > * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > > libtool is broken in this regard and needs to be fixed to survive
> > > > missing files.
> 
> > > Then fix it instead of giving people bad advice.
> 
> > Do you actually have anything beyond "libtool breaks otherwise, so it
> > *must* be good!"?  Here's some advice: rm *.la.  Yay, fixes the problem
> > *and* doesn't require everyone to add in dependencies that end up
> > pulling in hundreds of unneeded packages when trying to build something.
> 
> Dropping .la files, without also dropping .a files, will unnecessarily
> complicate matters for anyone statically linking against that lib.  As long
> as we still nominally support static linking, I expect that most lib
> maintainers are not going to be willing to do this.
> 
> But ok, yes, that is an option; let's spell the options out completely:
> 
> - Don't ship .la files in the -dev package; don't depend on any other -dev
>   packages except those whose headers you need.  This gives optimal results
>   for shared linking by pruning all unnecessary build-dependencies and
>   dependencies; but it also screws over anyone trying to do static linking,
>   who now has to go *recursively* hunt down the package name for each of the
>   library dependencies, based only on the names of the symbols exported.
>   (So why would anyone ship the static libs at this point...?)

If we want to support static linking then let's break it off into it's
own '-static' package with appropriate dependencies.  Personally I don't
think it's really worth it and we should just go ahead and drop the
static libraries too.  It'd certainly make the -dev packages alot
smaller.  Maybe then we could just put -dbg stuff in the -dev packages.
:)

> - Kill the .la files and .a files.  Drop support for static linking.  Not
>   something that should be done lightly and without prior project-wide
>   discussion.

We've had that discussion before.  Last I recall there wasn't really a
huge fight to keep them.

Stephen


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> > - Kill the .la files and .a files.  Drop support for static linking.  Not
> >   something that should be done lightly and without prior project-wide
> >   discussion.
> > - Leave the .la files in place; -dev packages need to depend on -dev
> >   packages corresponding to those runtime dependencies that are also
> > built using libtool.  This is the status quo.
> 
> - Option 4 (requires volunteers): fix libtool

Blankly stating that libtool needs to be 'fixed'
because it is 'broken' is not very helpful.
Would you care to explain what needs to be fixed and why 
it is broken?  Good working examples would be good.

The following are background informations, please do comment
if you find something is wrong about these:

libnewt is an example library that requires libslang.
The names are just symbollic; they just represent
random library.

fact 1: shared library 

  gcc -lnewt a.c
should work, since slang dependency is declared in NEEDED field
of libnewt.so, which the link will be resolved at run-time.

fact 2: static library

  gcc -lslang -lnewt a.c
is required for static lib linking, since .a files do not have
dependency information, and symbols need to be resolved at link time.


fact 3: libtool library
libtool tries to implement a wrapper around shared library and 
static library, so that both of them can be uniformly processed,
and allows specifying just:
  libtool cc -lnewt a.c

(implementation detail: .la files contain the dependency 
information for .a).


Debian implementation:

Packages Build-Depend on -dev packages they directly require,
thus a package requiring newt will Build-Depend on libnewt-dev,
but not libslang2-dev.

libnewt-dev will need to Depend on libslang2-dev, or
static lib compilation with libtool will break.

regards,
junichi

-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Langasek]

On Wed, Jul 27, 2005 at 10:16:54PM -0400, Josh Metzler wrote:
> On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
> > But ok, yes, that is an option; let's spell the options out completely:
> >
> > - Don't ship .la files in the -dev package; don't depend on any other
> > -dev packages except those whose headers you need.  This gives optimal
> > results for shared linking by pruning all unnecessary build-dependencies
> > and dependencies; but it also screws over anyone trying to do static
> > linking, who now has to go *recursively* hunt down the package name for
> > each of the library dependencies, based only on the names of the symbols
> > exported. (So why would anyone ship the static libs at this point...?)

> What about having the -dev packages recommend the -dev packages 
> corresponding to runtime dependencies that are built using libtool?  That 
> way the archive scripts wouldn't install them without a direct dependency, 
> but aptitude or dselect would do so.

Doesn't do a damn bit of good for the buildds.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Josh Metzler]

On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
> But ok, yes, that is an option; let's spell the options out completely:
>
> - Don't ship .la files in the -dev package; don't depend on any other
> -dev packages except those whose headers you need.  This gives optimal
> results for shared linking by pruning all unnecessary build-dependencies
> and dependencies; but it also screws over anyone trying to do static
> linking, who now has to go *recursively* hunt down the package name for
> each of the library dependencies, based only on the names of the symbols
> exported. (So why would anyone ship the static libs at this point...?)

What about having the -dev packages recommend the -dev packages 
corresponding to runtime dependencies that are built using libtool?  That 
way the archive scripts wouldn't install them without a direct dependency, 
but aptitude or dselect would do so.

> - Kill the .la files and .a files.  Drop support for static linking.  Not
>   something that should be done lightly and without prior project-wide
>   discussion.
> - Leave the .la files in place; -dev packages need to depend on -dev
>   packages corresponding to those runtime dependencies that are also
> built using libtool.  This is the status quo.

- Option 4 (requires volunteers): fix libtool

Josh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Langasek]

On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > libtool is broken in this regard and needs to be fixed to survive
> > > missing files.

> > Then fix it instead of giving people bad advice.

> Do you actually have anything beyond "libtool breaks otherwise, so it
> *must* be good!"?  Here's some advice: rm *.la.  Yay, fixes the problem
> *and* doesn't require everyone to add in dependencies that end up
> pulling in hundreds of unneeded packages when trying to build something.

Dropping .la files, without also dropping .a files, will unnecessarily
complicate matters for anyone statically linking against that lib.  As long
as we still nominally support static linking, I expect that most lib
maintainers are not going to be willing to do this.

But ok, yes, that is an option; let's spell the options out completely:

- Don't ship .la files in the -dev package; don't depend on any other -dev
  packages except those whose headers you need.  This gives optimal results
  for shared linking by pruning all unnecessary build-dependencies and
  dependencies; but it also screws over anyone trying to do static linking,
  who now has to go *recursively* hunt down the package name for each of the
  library dependencies, based only on the names of the symbols exported.
  (So why would anyone ship the static libs at this point...?)
- Kill the .la files and .a files.  Drop support for static linking.  Not
  something that should be done lightly and without prior project-wide
  discussion.
- Leave the .la files in place; -dev packages need to depend on -dev
  packages corresponding to those runtime dependencies that are also built
  using libtool.  This is the status quo.

> Yes, let's fix libtool.  No, I don't think we should screw over anyone
> trying to do development because it's broken.

...

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Stephen Frost]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > libtool is broken in this regard and needs to be fixed to survive
> > missing files.
> 
> Then fix it instead of giving people bad advice.

Do you actually have anything beyond "libtool breaks otherwise, so it
*must* be good!"?  Here's some advice: rm *.la.  Yay, fixes the problem
*and* doesn't require everyone to add in dependencies that end up
pulling in hundreds of unneeded packages when trying to build something.

Yes, let's fix libtool.  No, I don't think we should screw over anyone
trying to do development because it's broken.

> > libtool's brokenness just isn't a good enough reason to introduce all
> > these -dev -> -dev dependencies.
> 
> The fuck it isn't.  I'm not going to sit back while you run around crippling
> our ability to rebuild the archive just because you have an aesthetic
> objection to libtool.  *The only alternative to having -dev packages for
> libtool-using libraries depend on the -dev packages of other libtool-using
> libraries that they need is to have all libtool-using packages build-depend
> directly on all of those indirect dependencies*.  Until you present us with
> a libtool that includes a fix for this misfeature, and convince maintainers
> to *use* it in their packages, these are the only two options that give you
> buildable packages -- and having packages build-depend on all the indirect
> dependencies has a *much* higher crap factor.

Last time I checked Debian was about technical excellence.  It's sad to
see people fighting against that.  I thought it was about choice too
but apparently that's not it either.

Remove the .la files, or put them into the library packages themselves
instead of in the -dev packages, or fix libtool.  Certainly there are
better ways to deal with this problem than adding in lots of
dependencies for -dev packages.  Packages need to be changed one way or
another, let's make the changes that make sense instead of letting a
single (admittedly broken) application dictate poor policy.

Stephen


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Langasek]

On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > 4. -dev packages should depend on other -dev packages?

> >   Yes.

> Whoah, whoah, whoah.  This is just blatently false.  There *certainly*
> wasn't a consensus that -dev packages should regularly depend on -dev
> pacakges.  There's a couple corner cases where it's required (because
> the headers of one #include's headers from the other) but that
> definitely doesn't deserve a 'should'.  In fact, even those cases should
> generally be discouraged.

The "corner cases" where -dev packages must depend on other -dev packages
cover the majority of libraries in Debian.  If you mean *unanimous*
consensus, then you're right that we don't have it, but you're the only
hold-out that I see.

> libtool is broken in this regard and needs to be fixed to survive
> missing files.

Then fix it instead of giving people bad advice.

> libtool's brokenness just isn't a good enough reason to introduce all
> these -dev -> -dev dependencies.

The fuck it isn't.  I'm not going to sit back while you run around crippling
our ability to rebuild the archive just because you have an aesthetic
objection to libtool.  *The only alternative to having -dev packages for
libtool-using libraries depend on the -dev packages of other libtool-using
libraries that they need is to have all libtool-using packages build-depend
directly on all of those indirect dependencies*.  Until you present us with
a libtool that includes a fix for this misfeature, and convince maintainers
to *use* it in their packages, these are the only two options that give you
buildable packages -- and having packages build-depend on all the indirect
dependencies has a *much* higher crap factor.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> 1. Conclusion:
>  For the initial question of 
>   'How does one decide which -dev package accompanies
>   runtime library package'
>  There is no answer, and we have not reached the consensus.

It would be possible to put forth a proposal to deal with this, but it
needs to be something sensible.  Putting the SONAME in the -dev package
isn't sensible.  Perhaps something like:

libfooAPI-dev ; libfooAPI-SONAME

This is being done already, though 'API' is often just a major revision
number associated with the library.  ie:

libglib2.0-dev ; libglib2.0-0

So, pull off the stuff after the last -[0-9]* and add -dev and you've
got the -dev package.  I'm not sure there's enough packages doing this
to make it policy, but you could try to get people to accept it for new
libraries and convince existing maintainers to move to it.

> 3. -dev package names reflect API and runtime library packages reflect ABI?
> 
>   Apparently so, and sounds like a good idea that most people
>   agree on, there wasn't a real objection to this idea
>   modulo bugs on packages.

Bugs are bugs, and need to be fixed.

> 4. -dev packages should depend on other -dev packages?
> 
>   Yes.

Whoah, whoah, whoah.  This is just blatently false.  There *certainly*
wasn't a consensus that -dev packages should regularly depend on -dev
pacakges.  There's a couple corner cases where it's required (because
the headers of one #include's headers from the other) but that
definitely doesn't deserve a 'should'.  In fact, even those cases should
generally be discouraged.

>   Stephen Frost argued in this thread that -dev packages do not need to 
>   depend on other -dev packages, but due to 
>   things such as header files and libtool, 
>   there are cases which -dev packages depending on 
>   other -dev packages are rquired.

-dev packages depending on -dev packages should generally be avoided.  
It's true that if a -dev package includes header files from another 
-dev package then it does need to depend on it.  Thankfully, this is 
rare.  Generally it should be discouraged because it means that you've 
got two different APIs involved which just gives the opportunity for 
more bugs.  Honestly, these cases should be carefully reviewed and 
discussed with upstream as to if they understand the implications of it.

libtool is broken in this regard and needs to be fixed to survive
missing files.  libtool's brokenness just isn't a good enough reason to
introduce all these -dev -> -dev dependencies.  The static linking
argument is pretty much dead.  There was some discussion about having a
-dev (headers only) and a -static (static libs plus libtool cruft, w/
dependencies on other -static packages, etc) package for each library
but basically that'd really just be a stepping stone to then later drop
the -static packages.  Not sure there's really any point doing the
transistion to that just to drop it.

Thanks,

Stephen


signature.asc
Description: Digital signature

SUMMARY: Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

Since I've started up this thread, I'd like to summarize what was
discussed in this thread.


1. Conclusion:
 For the initial question of 
  'How does one decide which -dev package accompanies
  runtime library package'
 There is no answer, and we have not reached the consensus.

2. Methods to decide which -dev package matches runtime library package

  Currently: heuristically look at Packages file to see what packages are 
generated from same source.

3. -dev package names reflect API and runtime library packages reflect ABI?

  Apparently so, and sounds like a good idea that most people
  agree on, there wasn't a real objection to this idea
  modulo bugs on packages.

4. -dev packages should depend on other -dev packages?

  Yes.

  Stephen Frost argued in this thread that -dev packages do not need to 
  depend on other -dev packages, but due to 
  things such as header files and libtool, 
  there are cases which -dev packages depending on 
  other -dev packages are rquired.



regards,
junichi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]