Re: SUMMARY: Re: shared library -dev package naming proposal
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
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
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
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
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
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 [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
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
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 ([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 ([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
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
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
* 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
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
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
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
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
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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SUMMARY: Re: shared library -dev package naming proposal
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]
Re: SUMMARY: Re: shared library -dev package naming proposal
* 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
Re: SUMMARY: Re: shared library -dev package naming proposal
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
* 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
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
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
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: shared library -dev package naming proposal
Junichi Uekawa [EMAIL PROTECTED] wrote: 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. Errr, -dev packages generally don't (and shouldn't) depend on other -dev packages. If you're trying to push the idea that -dev packages should depend on the -dev packages of libraries they depend on- don't. That's *wrong*, it's the completely wrong approach and should *not* be taken. Give me justifications rather than just saying *wrong*, because you are giving me an argument that is contrary to current practice in Debian. -dev packages do depend on other -dev packages, and if they don't work, they are usually filed a serious bug for non-functionality. Reasons why you need you need to add a build-dependency on libfoo-dev package: - You're linking to it - You're using include files from it. Simular, if your package is libbar, your lib libbar-dev package needs to depends on the libfoo-dev packages if: - Your include files include libfoo's include files. This is ussually something you want to avoid. - You have a static lib, and people will need to link libfoo if they're linking to your package. I think static libs should be avoided in most cases. An other reason why it's currently done is that some packages link to packages that only use your libbar lib, but also link to libfoo, which isn't needed. Isn't not needed because libbar already depends on libfoo. This can for instance be the case when using libtool. The version of libtool in the archive shouldn't be doing this. The correct way to fix this is by updating the libtool package, or whatever that's being used, and not by having -dev packages depend on other/more -dev packages. It's just easier to fix this in the short time, because it only requires one -dev package to be fixed while else all packages build-depending on it need to be fixed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]: libfoobar-2.1-0 will have libfoobar-2.1-0-dev. Please distinguish between API and ABI! -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! the liar at any rate recognises that recreation, not instruction, is the aim of conversation, and is a far more civilised being than the blockhead who loudly expresses his disbelief in a story which is told simply for the amusement of the company. -- oscar wilde signature.asc Description: Digital signature
Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)
Hi, BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. Yes and no. The programer can overlook the soname change for the source. The API hasn't changed and nothing needs to adjust for the new soname. The packaging system won't let the binary forget the soname change though as that is part of the package name of the libary. Binaries will keep using the old lib till they are recompiled. I'm talking about the following case: 1. libA depends on libB1, but only build-depends on libB-dev 2. libB1 changes to be libB2. 3. libA is rebuilt with libB2 without maintainer noticing (could happen on buildd, etc.), possibly creating a noncompatible interface. It would be a practical case especially when libB1, libB2 are not using versioned symbols. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, Thanks for your input. Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. If this is actually necessary for libtool-using packages, then write something which goes through all of the .la files and does this, since that's what libtool wants to do. and Errr, you still havn't said what problem you're trying to solve with this yet. 1. To derive dependency information from libtool-using packages, it is currently possible to derive lists of shared library packages. 2. In general, there is a leap in shared library packages and -dev package, and it's not possible to get a -dev package which is for a given shared library package. I envision that it would be nice to be able to agree on some kind of naming style so that it is possible to deduce the name of development library in some mechanical manner. It's not just because of autogenerating -dev dependencies, but about usability of Debian as a Development platform : $ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/' libshared0-dev An alternate solution is to have a database for that kind of thing, but I forsee that it requires effort to maintain and keep up-to-date. It's rather embarassing to know that Debian isn't organized at all in this manner. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. With the current scheme it is: ldd /usr/lib/libwhatever.so to track down its shared library dependency, strip the soversion and appending -dev to individual package to create the list of requisite -dev packages. And, by the way, that list is just plain wrong. Okay, currently d-shlibs is using objdump, and does not recursively look for dependencies. gotom suggested to use ldd, to obtain the full path of shared libraries, and I do see the limitation with using ldd, as you pointed out illustratively in your example. regards, junchi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote: also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]: libfoobar-2.1-0 will have libfoobar-2.1-0-dev. Please distinguish between API and ABI! True. Indeed the proposed policy is already followed in case of ABI changes. And any sane program would not compile when ever a library change its _API_ in a way not back-compatible. If not, well that's an upstream issue, not a debian one :) -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. Yes and no. The programer can overlook the soname change for the source. The API hasn't changed and nothing needs to adjust for the new soname. The packaging system won't let the binary forget the soname change though as that is part of the package name of the libary. Binaries will keep using the old lib till they are recompiled. I'm talking about the following case: 1. libA depends on libB1, but only build-depends on libB-dev 2. libB1 changes to be libB2. 3. libA is rebuilt with libB2 without maintainer noticing (could happen on buildd, etc.), possibly creating a noncompatible interface. It would be a practical case especially when libB1, libB2 are not using versioned symbols. Versioned symbols has nothing to do with this case. If the API changes (what you're talking about above) then perhaps the -dev name should change. Tieing the -dev name to the SONAME (ie: A*B*I) is not an appropriate fix for dealing with API changes. Quite a few packages already handle this by having a version in the name of all the packages, and then having a *seperate* incremented number in the name of the lib package for the SONAME. That's the correct way to solve this problem, not trying to tie the ABI and the API together. In fact, I believe glib2.0 is an example of this: glib2.0-0 - The actual library, with the '0' revision of the ABI glib2.0-dev - The headers, ie: API, for glib2.0. This essentially says that the A*P*I for glib2.0 won't change in a backwards-incompatible way. If it does, then it's a bug and needs to be fixed. This does allow for A*B*I changes, which require only a recompile of the application (because the API hasn't changed). Now, there is a seperate issue with libtool-using libraries and .la dependencies, but that's exactly what it is, a seperate issue. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: If this is actually necessary for libtool-using packages, then write something which goes through all of the .la files and does this, since that's what libtool wants to do. and Errr, you still havn't said what problem you're trying to solve with this yet. 1. To derive dependency information from libtool-using packages, it is currently possible to derive lists of shared library packages. 2. In general, there is a leap in shared library packages and -dev package, and it's not possible to get a -dev package which is for a given shared library package. Shared library packages and -dev packages represent different things. I envision that it would be nice to be able to agree on some kind of naming style so that it is possible to deduce the name of development library in some mechanical manner. It's not just because of autogenerating -dev dependencies, but about usability of Debian as a Development platform : $ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/' libshared0-dev Having a single naming style is somewhat difficult for libraries because different upstreams choose to represent API changes differently. An example of this is OpenLDAP- their API hasn't ever changed in a backwards-incompatible way (or so they tell me). They do add things to their API over time, though I think they generally try to do those around major releases (2.0, 2.1, 2.2, 2.3, etc). They also change the ABI without (unfortunately) much hesitation. The ABI changes need to be tracked using the SONAME, but technically we could have just one 'libldap-dev' since OpenLDAP 1.3. This isn't true for other upstreams, such as glib, which, I infer from their naming scheme anyway, has API changes generally around major releases, and those changes aren't backwards-compatible. (ie: 1.3 to 2.0, or what have you). Tieing the API to the SONAME is a *bad* idea, it implies changes where there aren't any and requires changes to packages that aren't necessary. Honestly, I think it'd be nice if we could teach the buildds to automatically rebuild packages when the API hasn't changed. I'd think that'd make some of these transistions that we have to go through on occation go alot faster. An alternate solution is to have a database for that kind of thing, but I forsee that it requires effort to maintain and keep up-to-date. It's rather embarassing to know that Debian isn't organized at all in this manner. Back to my previous comment- you've got people who aren't familiar with SONAMES and ABIs writing libraries. I don't feel that's *Debian's* fault, though we do try to deal with it as best we can. This suggestion doesn't help that issue one bit though. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
* Francesco P. Lovergine ([EMAIL PROTECTED]) wrote: On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote: also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]: libfoobar-2.1-0 will have libfoobar-2.1-0-dev. Please distinguish between API and ABI! True. Indeed the proposed policy is already followed in case of ABI changes. And any sane program would not compile when ever a library change its _API_ in a way not back-compatible. If not, well that's an upstream issue, not a debian one :) Exactly! :) We must have a seperate tracking of API and ABI changes. To do otherwise is madness. Stephen signature.asc Description: Digital signature
Re: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)
Junichi Uekawa [EMAIL PROTECTED] writes: Hi, BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. Yes and no. The programer can overlook the soname change for the source. The API hasn't changed and nothing needs to adjust for the new soname. The packaging system won't let the binary forget the soname change though as that is part of the package name of the libary. Binaries will keep using the old lib till they are recompiled. I'm talking about the following case: 1. libA depends on libB1, but only build-depends on libB-dev 2. libB1 changes to be libB2. 3. libA is rebuilt with libB2 without maintainer noticing (could happen on buildd, etc.), possibly creating a noncompatible interface. It would be a practical case especially when libB1, libB2 are not using versioned symbols. If libB1 and libB2 are only an ABI change but not an API change then libA will just compile and then have a Depends: libB2 automaticaly. That is fully intentional. If libB1 and libB2 have different APIs then the libB maintainer screwed up. API changes must eigther be reflected in the libBapi_number-dev name (e.g. libpng2-dev, libpng12-dev) or the maintainer must make damn sure all rdepends are updated along with libB (suboptimal). Since several people have started to infrequently recompile all of debian to see if any sources broke any violations of this will get noticed. regards, junichi MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Junichi Uekawa [EMAIL PROTECTED] writes: Hi, Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. You could also suggest a policy for libs to have a libfoo.devname file similar to the libfoo.shlibs file but naming the needed -dev packages. If that is a good idea or not you have to think about. Just a wild idea. With the current scheme it is: ldd /usr/lib/libwhatever.so to track down its shared library dependency, strip the soversion and appending -dev to individual package to create the list of requisite -dev packages. And, by the way, that list is just plain wrong. Okay, currently d-shlibs is using objdump, and does not recursively look for dependencies. gotom suggested to use ldd, to obtain the full path of shared libraries, and I do see the limitation with using ldd, as you pointed out illustratively in your example. You have to do both. ldd for the full path and then filter that with objdump. That is how dpkg-shlibdeps does it if I read the code right. regards, junchi MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, Thanks for your time and feedback. I appreciate it very much. You could also suggest a policy for libs to have a libfoo.devname file similar to the libfoo.shlibs file but naming the needed -dev packages. If that is a good idea or not you have to think about. Just a wild idea. Yes, that's basically what shlibs file is doing for shared libraries. I was hoping that it was more practical to have a Provides: field or a package name that can be linked from the shared library package. Stephen Frost has explained to me that -dev package names apparently express their API, and their maintainers can be beaten to whatever when they break, and I kind of agree that might even be a good idea, I would like to drop the idea of unanimously requesting packages to name their -dev packages thus way. From the standpoint of a Debian user, it still stands that shared library packages and -dev packages (which has a symlink pointing to the shared library package) do not have an explicit relationship declared in Debian, except for the fact that they are often created from the same source. Stephen's points are valid and quite useful considering an upstream developer's point of view, but for random user joe who is trying to find a development package, one of the following may help him find the right package 1. creating a system-wide list of what -dev package does what. - centrally requires work. Already started in d-shlibs. 2. creating a devlibs file which points to what shared library is handled by which -dev package. - requires manual intervention by all developers, and utilizes an i-node for all shared library installations. 3. creating a package policy to Provides: a symbollic name that can be traced from the shared library package name or the shared library soname. - non-invasive if it's done gradually. Okay, currently d-shlibs is using objdump, and does not recursively look for dependencies. gotom suggested to use ldd, to obtain the full path of shared libraries, and I do see the limitation with using ldd, as you pointed out illustratively in your example. You have to do both. ldd for the full path and then filter that with objdump. That is how dpkg-shlibdeps does it if I read the code right. Thanks for pointing that out. This knowledge may become useful when ldd output can be converted to a list of -dev packages. regards, junichi
Re: shared library -dev package naming proposal
On Fri, Jul 15, 2005 at 10:44:04PM +0900, Junichi Uekawa wrote: Stephen's points are valid and quite useful considering an upstream developer's point of view, but for random user joe who is trying to find a development package, one of the following may help him find the right package 1. creating a system-wide list of what -dev package does what. - centrally requires work. Already started in d-shlibs. 2. creating a devlibs file which points to what shared library is handled by which -dev package. - requires manual intervention by all developers, and utilizes an i-node for all shared library installations. 3. creating a package policy to Provides: a symbollic name that can be traced from the shared library package name or the shared library soname. - non-invasive if it's done gradually. Make shared library packages Suggest: their corresponding -dev packages. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Stephen's points are valid and quite useful considering an upstream developer's point of view, but for random user joe who is trying to find a development package, one of the following may help him find the right package Joe user should do: apt-cache search libNAME dev (or use synaptic, aptitude, etc.) That's what do I do when I search for library. Ondrej. -- Ondrej Sury [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)
On Fri, Jul 15, 2005 at 05:18:23PM +0900, Junichi Uekawa wrote: BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. Yes and no. The programer can overlook the soname change for the source. The API hasn't changed and nothing needs to adjust for the new soname. The packaging system won't let the binary forget the soname change though as that is part of the package name of the libary. Binaries will keep using the old lib till they are recompiled. I'm talking about the following case: 1. libA depends on libB1, but only build-depends on libB-dev 2. libB1 changes to be libB2. 3. libA is rebuilt with libB2 without maintainer noticing (could happen on buildd, etc.), possibly creating a noncompatible interface. That's the part that needs to be fixed. It would be a practical case especially when libB1, libB2 are not using versioned symbols. Except that libB *should* be using versioned symbols, for all libB where there exists a libA that depends on it. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote: Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. If this is actually necessary for libtool-using packages, then write something which goes through all of the .la files and does this, since that's what libtool wants to do. and Errr, you still havn't said what problem you're trying to solve with this yet. 1. To derive dependency information from libtool-using packages, it is currently possible to derive lists of shared library packages. 2. In general, there is a leap in shared library packages and -dev package, and it's not possible to get a -dev package which is for a given shared library package. I envision that it would be nice to be able to agree on some kind of naming style so that it is possible to deduce the name of development library in some mechanical manner. It's not just because of autogenerating -dev dependencies, but about usability of Debian as a Development platform : $ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/' libshared0-dev $ apt-cache showsrc $(dpkg -S /usr/lib/libxslt.so.1 | cut -f1 -d:) \ | sed -n -e's/^Binary: //p' | sed -e's/,[[:space:]]\+/\n/g' | grep -- -dev \ | sort -u libxslt1-dev $ Can be refined to only query sources for a particular dist, etc. Can't cope with multiple -dev packages from a single source package without recourse to the Contents files. OTOH, your solution just don't seem to offer much unless *all* packages conform to the proposed scheme, and it's already been argued that there are cases that your scheme doesn't address... and even if everyone agreed it was a good idea, it would take a long time before developers would get the benefits of it, because of all the conversions that would need to take place. I just don't see the point. An alternate solution is to have a database for that kind of thing, but I forsee that it requires effort to maintain and keep up-to-date. Like the database I just queried above? :) It's rather embarassing to know that Debian isn't organized at all in this manner. You seem to be embarrassed easily. If this is such a problem for using Debian as a development platform, why is this the first time I've seen the subject discussed on debian-devel? I'm not convinced that the problem you're trying to solve is of sufficiently general interest to outweigh all of the other problems it introduces (such as the ones that have been pointed out in this thread). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
On 7/15/05, Steve Langasek [EMAIL PROTECTED] wrote: On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote: An alternate solution is to have a database for that kind of thing, but I forsee that it requires effort to maintain and keep up-to-date. Like the database I just queried above? :) There's an even better one called Google. If you're adding a library dependency to a package that you plan to maintain for the benefit of a large number of users, you might want to know a little more about the library, its upstream, and its packager than just what the relationship is between foo.sf.net, foo-X.X.tgz, and the binary package names. Automated tools, on the other hand, can and should be primed with data, not heuristics. Test suites _should_ be fragile so that if something changes in a remotely questionable way you _spot_ it. Then you use a heuristic, if available, to update the priming data and touch it up manually where necessary. Automate where it helps, not where it hurts. It's rather embarassing to know that Debian isn't organized at all in this manner. Organization is overrated. While good code is, in the long run, an aesthetic criterion as much as anything else, some aesthetic instincts can be misleading. Cathedral / bazaar, and all that. (Though I personally prefer cathedrals, and if you've read about how they were actually built, you will see that the Linux, glibc, GCC, perl, python, etc. development process looks much more like cathedral building than like the Kasbah.) You seem to be embarrassed easily. If this is such a problem for using Debian as a development platform, why is this the first time I've seen the subject discussed on debian-devel? There may well be useful tools that are made harder to write by the indiscriminate naming of packages. For an example where the global aesthetic criterion does tend to win, at the expense of some use cases, consider the prejudice against splitting off micro-packages to slim down the dependencies of the main binary package. tetex-bin comes to mind -- and don't tell me that tetex-base is the main package, because it's tetex-bin that is needed when building X11 (last time I checked; still true of xfree86 in unstable; apparently also true of xorg). Perhaps it's not worth splitting out xpdf as a separate source package to break the circular build-depends -- although it would avoid gratuitous security updates to the rest of tetex. But I for one really don't like having to have the binary packages from an old xfree86 build installed in order to do a new build. Yeah, you can build your own tetex-bin with xpdf excluded, or just force-install tetex-bin without the X libs in a chroot -- but it's ugly. I know that the package count is getting to be a scalability problem and that people are working on ways of dealing with that, and in the meantime there is some rational pressure not to split packages needlessly. I'm not blaming the TeTeX team for weighing the factors and deciding not to split. I'm just giving an example of a warning sign that too many meanings are being overloaded onto one technical distinction -- in this case, the boundaries of a .deb. Another example would be localization packages; I hope I don't need to spell that one out. I'm not convinced that the problem you're trying to solve is of sufficiently general interest to outweigh all of the other problems it introduces (such as the ones that have been pointed out in this thread). IMHO the problem is real, the solution is wrong. Don't try to organize the underlying data; add enough metadata markup that you can present better organized views for various purposes. Don't rush to add that metadata to debian/control; sketch out a heuristic using existing metadata that leaves you with a relatively small number of manual overrides, write real applications that use it, and then decide if it's OK to keep the manual overrides as detached metadata or if they belong in debian/control. Cheers, - Michael
Re: shared library -dev package naming proposal
[I am stopping the cross-posting to -release, as -release is no discussion list] On 2005-07-14 Junichi Uekawa [EMAIL PROTECTED] wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. If the library package is named lib$NAME, call the -dev package lib$NAME-dev. [...] Hej, The obvious downside of this is that the name of dev-package will change although the API did not necessarily change. This would increase workload for stuff like the current C++ transition and makes backporting more difficult. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
shared library -dev package naming proposal
Hi, I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. If the library package is named lib$NAME, call the -dev package lib$NAME-dev. For example, libxxx0 will have libxxx0-dev. libfoobar-2.1-0 will have libfoobar-2.1-0-dev. This allows mechanically determining shared library package and corresponding -dev package. This was raised in the Shared library BOF @ Debconf5 which was held this morning. For transition purposes, I would like this only to be enforced on new packages, since renaming every single -dev package would be prohibitively intrusive, but would like to enforce this rule for new packages. Comments? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. Uh, no? The -dev packages have no need to match to a specific runtime library and this just creates unnecessary work. This allows mechanically determining shared library package and corresponding -dev package. Eh? How about you go a bit deeper into why that's necessary and how that's not possible today? What problem are you trying to solve with this? This was raised in the Shared library BOF @ Debconf5 which was held this morning. Clearly something's missing here 'cause you havn't provided any rational for why this would be a good thing and honestly it certainly looks like a bad thing(tm) to do to me. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
On Thu, 2005-07-14 at 20:16 +0900, Junichi Uekawa wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. I personally found it very handy that the dev packages automatically selects the most recent API compatible version. Why do you want this switch by the way? You did not name reasons as far as I could see. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. If the library package is named lib$NAME, call the -dev package lib$NAME-dev. [...] Hej, The obvious downside of this is that the name of dev-package will change although the API did not necessarily change. This would increase workload for stuff like the current C++ transition and makes backporting more difficult. Thanks for pointing these points out. My impression is that your point can be addressed as follows: 1. libwhateverXXX-dev can (and in most cases must) provide (and conflict) with libwhatever-dev, so the first point is moot. 2. However, versioned depends will suffer, but having a versioned depends will make moot the problem with backporting and C++ transition. There may be other showstoppers. I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, * Junichi Uekawa ([EMAIL PROTECTED]) wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. Uh, no? The -dev packages have no need to match to a specific runtime library and this just creates unnecessary work. Well, I will list the rationale; it might have been a bit of an abrupt mail for those who did not attend today's talk. 1. usually -dev packages have a symlink to the shared library contained in the runtime shared library package. 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. 3. d-shlibs provides an infrastracture for generating devlibs:Depends for debian/control, but it has a long sed rule for replacing -dev package names; it shoulnd't really neeed them. 4. I'm only requesting NEW packages to come under this naming scheme, we'll try to cover the old packages with some kind of sed script or replacement rule. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: There may be other showstoppers. What does doing this solve? What does it even help with? I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) non-regulation? What non-regulation? What regulation? Indeed, I'm not sure there *isn't* majority agreement- it's just that you're in the minority... That doesn't a concensus make, but, well, you'd have to change your mind and you don't seem too keen on doing that.. The only good solution is to not let people who don't know how to handle API and ABI changes and understand SONAMEs and how loaders and symbols work to write libraries. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: * Junichi Uekawa ([EMAIL PROTECTED]) wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. Uh, no? The -dev packages have no need to match to a specific runtime library and this just creates unnecessary work. Well, I will list the rationale; it might have been a bit of an abrupt mail for those who did not attend today's talk. 1. usually -dev packages have a symlink to the shared library contained in the runtime shared library package. Uhh, this isn't a reason for them to have the major SO version in the name of the -dev package. 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. Errr, -dev packages generally don't (and shouldn't) depend on other -dev packages. If you're trying to push the idea that -dev packages should depend on the -dev packages of libraries they depend on- don't. That's *wrong*, it's the completely wrong approach and should *not* be taken. 3. d-shlibs provides an infrastracture for generating devlibs:Depends for debian/control, but it has a long sed rule for replacing -dev package names; it shoulnd't really neeed them. This doesn't sound quite right either. Looks at 'd-shlibs', it sounds like it's doing the *wrong* thing anyway. 4. I'm only requesting NEW packages to come under this naming scheme, we'll try to cover the old packages with some kind of sed script or replacement rule. Again, not a reason to follow the proposal at all. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
Junichi Uekawa [EMAIL PROTECTED] writes: Hi, I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. If the library package is named lib$NAME, call the -dev package lib$NAME-dev. [...] Hej, The obvious downside of this is that the name of dev-package will change although the API did not necessarily change. This would increase workload for stuff like the current C++ transition and makes backporting more difficult. Thanks for pointing these points out. My impression is that your point can be addressed as follows: 1. libwhateverXXX-dev can (and in most cases must) provide (and conflict) with libwhatever-dev, so the first point is moot. 2. However, versioned depends will suffer, but having a versioned depends will make moot the problem with backporting and C++ transition. You can (and it is often done) extend an api to include more functionality without breaking the existing api. Any program using one of the new functions must use a versioned depend on the libfoo-dev package introducing the function. The API can (and will) even stay compatibly across ABI changes like the c++ transition or changes in one of the sub libarries. So having an unversioned provide is quite unsatisfactory and having versioned depends on the libfoo-dev quite common. Lets do a very rough count: [EMAIL PROTECTED]:~% grep-dctrl -F Build-Depends dev ( /mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc 16633326 31941 There may be other showstoppers. I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) It has worked for the last 10 years so why change it now? Till now you seem to only show your nameing scheme isn't worse but not why it is better. Or can you show any problems in the current names? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
[once more, doesn't belong on -release...] On Thu, Jul 14, 2005 at 12:11:21PM -0400, Stephen Frost wrote: * Junichi Uekawa ([EMAIL PROTECTED]) wrote: * Junichi Uekawa ([EMAIL PROTECTED]) wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. Uh, no? The -dev packages have no need to match to a specific runtime library and this just creates unnecessary work. Well, I will list the rationale; it might have been a bit of an abrupt mail for those who did not attend today's talk. 1. usually -dev packages have a symlink to the shared library contained in the runtime shared library package. Uhh, this isn't a reason for them to have the major SO version in the name of the -dev package. 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. Errr, -dev packages generally don't (and shouldn't) depend on other -dev packages. If you're trying to push the idea that -dev packages should depend on the -dev packages of libraries they depend on- don't. That's *wrong*, it's the completely wrong approach and should *not* be taken. It's more or less mandatory for libtool-based packages, due to a historical misfeature of libtool; it's the only way to ensure static libs from any particular -dev package are in a usable state; and it's essential when use of the -dev package depends on the availability of headers from other -dev packages. That's not a very strong rationale for the proposed policy, but the -dev dependencies themselves are (unfortunately) warranted. -- Steve Langasek postmodern programmer
Re: shared library -dev package naming proposal
Hi, There may be other showstoppers. What does doing this solve? What does it even help with? Hmmm... we are talking about naming Debian development shareed library package names based on Debian runtime shared library package names. I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) non-regulation? What non-regulation? What regulation? Indeed, I'm not sure there *isn't* majority agreement- it's just that you're in the minority... That doesn't a concensus make, but, well, you'd have to change your mind and you don't seem too keen on doing that.. The only good solution is to not let people who don't know how to handle API and ABI changes and understand SONAMEs and how loaders and symbols work to write libraries. This is not a relevant point, since I'm talking about the Debian packaging, not how upstream should code. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. I personally found it very handy that the dev packages automatically selects the most recent API compatible version. Why do you want this switch by the way? You did not name reasons as far as I could see. The current recommendation I'm trying to give is: Package: libXXX-dev Conflicts: libXXX-dev Provides: libXXX-dev Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
On Thursday 14 July 2005 17:14, Junichi Uekawa wrote: The current recommendation I'm trying to give is: Package: libXXX-dev Conflicts: libXXX-dev Provides: libXXX-dev Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. I may be wrong, but I thought it was incorrect to build-dep only on a pure virtual package? e.g.: Build-Depend: xlibmesa-gl-dev | libgl-dev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, You can (and it is often done) extend an api to include more functionality without breaking the existing api. Any program using one of the new functions must use a versioned depend on the libfoo-dev package introducing the function. The API can (and will) even stay compatibly across ABI changes like the c++ transition or changes in one of the sub libarries. So having an unversioned provide is quite unsatisfactory and having versioned depends on the libfoo-dev quite common. Lets do a very rough count: [EMAIL PROTECTED]:~% grep-dctrl -F Build-Depends dev ( /mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc 16633326 31941 You have a point, that probably makes libfoo-dev being a unversioned provides to be a problem. There may be other showstoppers. I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) It has worked for the last 10 years so why change it now? Till now you seem to only show your nameing scheme isn't worse but not why it is better. Or can you show any problems in the current names? Currently, it's unordered. Say a shared library package has the following: libfoo-0.1-0 The development package looks like one of the following or another random incarnation: 1. libfoo-dev 2. libfoo-0.1-dev 3. libfoo-0.1-0-dev 1 and 2 cannot easily be deduced from the shared library package name, and I am proposing using 3 as a means of deducing the -dev package name. However, the goal of having an information to shared library package name with development package name can be achieved by having the package name in the Provides: field, so that might be a less disruptive approach. BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: There may be other showstoppers. What does doing this solve? What does it even help with? Hmmm... we are talking about naming Debian development shareed library package names based on Debian runtime shared library package names. Errr, you still havn't said what problem you're trying to solve with this yet. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. Uh, no it isn't. SONAME changes are fine, the package has to be rebuilt, but that's not an issue if the API hasn't changed. If the API has changed then it's more than an SONAME change and people will need to adjust code which depends on it. That's not solved by putting the SONAME into the -dev package, you'd need an API revision number in the -dev package to deal with that (which a number of things do, and which is good). Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
Hi, 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. Errr, -dev packages generally don't (and shouldn't) depend on other -dev packages. If you're trying to push the idea that -dev packages should depend on the -dev packages of libraries they depend on- don't. That's *wrong*, it's the completely wrong approach and should *not* be taken. Give me justifications rather than just saying *wrong*, because you are giving me an argument that is contrary to current practice in Debian. -dev packages do depend on other -dev packages, and if they don't work, they are usually filed a serious bug for non-functionality. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: The current recommendation I'm trying to give is: Package: libXXX-dev Conflicts: libXXX-dev Provides: libXXX-dev Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. Uhh, then it doesn't fix your 'QA' concern anyway... Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. If this is actually necessary for libtool-using packages, then write something which goes through all of the .la files and does this, since that's what libtool wants to do. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
#include hallo.h * Will Newton [Thu, Jul 14 2005, 05:36:05PM]: Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. I may be wrong, but I thought it was incorrect to build-dep only on a pure virtual package? e.g.: Build-Depend: xlibmesa-gl-dev | libgl-dev I just though the same. In addition, that proposal removes the possibility to depend on a certain -dev package and all newer versions (by setting a versioned dependency on libfoo-dev). Regards, Eduard. -- vicbro ich kotz gleich. warum reichen 512mb nicht für konqueror, konsole, kopete, kontact, ksirc, openoffice und 10 weitere programme aus? jjFux kbloat, kmemeater, kleak ... signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
Will Newton [EMAIL PROTECTED] writes: On Thursday 14 July 2005 17:14, Junichi Uekawa wrote: The current recommendation I'm trying to give is: Package: libXXX-dev Conflicts: libXXX-dev Provides: libXXX-dev Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. I may be wrong, but I thought it was incorrect to build-dep only on a pure virtual package? e.g.: Build-Depend: xlibmesa-gl-dev | libgl-dev Indeed. apt-get build-dep will regulary fall over Build-Depends on virtual packages. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Junichi Uekawa [EMAIL PROTECTED] writes: Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. With the current scheme it is: ldd /usr/lib/libwhatever.so to track down its shared library dependency, strip the soversion and appending -dev to individual package to create the list of requisite -dev packages. And, by the way, that list is just plain wrong. Say you have: libfoobar1 depends (only on) libfoo1, libfoo1 depends libbar1. YOU would get: libfoo1: Depends: libbar1-dev libfoobar1-dev Depends: libfoo1-dev, libbar1-dev. Now libbar2 is uploaded and libfoo1 recompiled with libbar2: libfoobar1 depends libfoo1, libfoo1 depends libbar2. libfoo1: Depends: libbar2-dev libfoobar1-dev is now uninstallable for no good reason at all. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Junichi Uekawa [EMAIL PROTECTED] writes: BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. Yes and no. The programer can overlook the soname change for the source. The API hasn't changed and nothing needs to adjust for the new soname. The packaging system won't let the binary forget the soname change though as that is part of the package name of the libary. Binaries will keep using the old lib till they are recompiled. You see, nothing breaks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
