Re: conditional dependency?
[Stephen Gran] I really hope that's not true. There are many useful use cases for static linking when you're building for constrained or otherwise not quite sane environments that IMHO we should continue to support. Since in the main it's not that hard to do the right thing, it's also of limited value to discourage it. It is worth to note that glibc do not work properly with static linking. All functions using PAM and NSS do not work, so binaries using such functions will fail when presented with incompatible modules on disk. This normally make static linking useless to make sure binaries keep working independently of the shared libraries available on disk. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008, Steve Langasek wrote: Conventionally, library -dev packages do depend on other -dev packages that they require for static linking; and certainly, tools like pkg-config and libtool (and other home-grown foo-config scripts) tend to encourage this behavior. Nowadays, with a proper .pc file I would argue that this could be reduced to a Recommends. Cannot be reduced: pkg-config needs to be able to go down Requires.private modules to compute Cflags and hence you have to Depend on Requires.private modules (as if they are missing, pkg-config calls simply fail). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008, Nikita V. Youshchenko wrote: And what if somebody will try to link statically? Your -config binary should gain a --static flag to distinguish between the two uses. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
This one time, at band camp, Petter Reinholdtsen said: [Stephen Gran] I really hope that's not true. There are many useful use cases for static linking when you're building for constrained or otherwise not quite sane environments that IMHO we should continue to support. Since in the main it's not that hard to do the right thing, it's also of limited value to discourage it. It is worth to note that glibc do not work properly with static linking. All functions using PAM and NSS do not work, so binaries using such functions will fail when presented with incompatible modules on disk. That's pretty much always been the case with at least NSS, by design. That being said, the interface to nss hasn't particularly changed in so long I'm not sure this is an issue, in practice. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: conditional dependency?
On Tue, Feb 26, 2008 at 12:03:06PM +, Stephen Gran wrote: This one time, at band camp, Petter Reinholdtsen said: [Stephen Gran] I really hope that's not true. There are many useful use cases for static linking when you're building for constrained or otherwise not quite sane environments that IMHO we should continue to support. Since in the main it's not that hard to do the right thing, it's also of limited value to discourage it. It is worth to note that glibc do not work properly with static linking. All functions using PAM and NSS do not work, so binaries using such functions will fail when presented with incompatible modules on disk. That's pretty much always been the case with at least NSS, by design. That being said, the interface to nss hasn't particularly changed in so long I'm not sure this is an issue, in practice. Broken glibc due to static linking is an issue at least weekly on embedded linux mailing lists (eg buildroot). ie it's still an issue. What are the constrained environments where you think static linking would be useful? I'm developing embedded systems and I prefer shared libraries - unless you have only one application using a particular library then you will save space. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Tue, Feb 26, 2008 at 11:26:30PM +1100, Hamish Moffatt wrote: What are the constrained environments where you think static linking would be useful? I'm developing embedded systems and I prefer shared libraries - unless you have only one application using a particular library then you will save space. Desktop grid applications that will be running on an unknown version of an unknown distribution, but I want to be able to build them on Debian. These applications won't ever use NSS, PAM or anything else that relies on some system-level configuration because you can't assume anything about the local system. 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: conditional dependency?
On Mon, Feb 25, 2008 at 11:07:10PM +, Roger Leigh wrote: I stopped providing static libraries in all my library packages quite a while back. No one used them, and they were just needless bloat. I can't say I would be upset if we dropped all the static libraries from the entire archive--is there actually a real world requirement for them in 2008? Yes, desktop grid applications. 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: conditional dependency?
On Mon, Feb 25, 2008 at 10:56:09PM +0300, Nikita V. Youshchenko wrote:
Hi
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using ${shlib:Depends},
however libdev package dependency on libcurl4-gnutls-dev is manually
written in debian/control file. The build package dependency is valuable
since -lcurl is among 'libetpan-config --ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package dependency.
It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on
exact one that was actually used when building package.
How to handle this properly?
Just trim -lcurl from libetpan-config's output and remove the dependency
altogether.
Obviously, don't do this if libetpan's reverse deps *need* to build with
-lcurl (which is unlikely)
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 10:56:09PM +0300, Nikita V. Youshchenko wrote:
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using ${shlib:Depends},
however libdev package dependency on libcurl4-gnutls-dev is manually
written in debian/control file. The build package dependency is valuable
since -lcurl is among 'libetpan-config --ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package dependency.
It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on
exact one that was actually used when building package.
How to handle this properly?
Fix libetpan-config on Debian to not return libraries that are only related
to static linking, and drop libcurl4-gnutls-dev to a Recommends?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Just trim -lcurl from libetpan-config's output and remove the dependency altogether. Obviously, don't do this if libetpan's reverse deps *need* to build with -lcurl (which is unlikely) And what if somebody will try to link statically? Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). signature.asc Description: This is a digitally signed message part.
Re: conditional dependency?
On Mon, Feb 25, 2008 at 11:48:21PM +0300, Nikita V. Youshchenko wrote: While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Just trim -lcurl from libetpan-config's output and remove the dependency altogether. Obviously, don't do this if libetpan's reverse deps *need* to build with -lcurl (which is unlikely) And what if somebody will try to link statically? Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). Add a --static flag to libetpan-config. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 23:48:21 +0300, Nikita V. Youshchenko wrote: Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). That's not true, afaik. If you're linking statically, you have to figure out dependencies on your own. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 11:48:21PM +0300, Nikita V. Youshchenko wrote: While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Just trim -lcurl from libetpan-config's output and remove the dependency altogether. Obviously, don't do this if libetpan's reverse deps *need* to build with -lcurl (which is unlikely) And what if somebody will try to link statically? Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). Add a --static flag to libetpan-config. How will this make dependency unneeded? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 10:56:09PM +0300, Nikita V. Youshchenko wrote:
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using
${shlib:Depends}, however libdev package dependency on
libcurl4-gnutls-dev is manually written in debian/control file. The build
package dependency is valuable since -lcurl is among 'libetpan-config
--ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting
support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package
dependency. It should depend not on libcurl4-gnutls-dev |
libcurl3-gnutls-dev, but on exact one that was actually used when
building package.
How to handle this properly?
Fix libetpan-config on Debian to not return libraries that are only
related to static linking, and drop libcurl4-gnutls-dev to a Recommends?
This looks against how librarieshave been packaged in the past.
In particular, Debian Library Packaging guide [0], sec 6.2, states that
libdev package should depend on all libdev packages that the library
package directly depends upon.
Did something change recently?
Maybe I missed something?
Coukd you please provide any pointers to how libraries should be packaged
today?
[0] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
(referenced from sec 6.7.2 of Developer Reference)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
Nikita V. Youshchenko wrote:
Hi
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using ${shlib:Depends},
however libdev package dependency on libcurl4-gnutls-dev is manually
written in debian/control file. The build package dependency is valuable
since -lcurl is among 'libetpan-config --ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package dependency.
It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on
exact one that was actually used when building package.
In general alternative build dependencies are not recomended as we want
to have a predictable build process. The main thing when backporting is
changing build dependencies AFAICS. Normaly the intention is to change
as less as possible between the old version and the backported version's
environment unless necessary for new features AFAICT, so for someone who
is used to backport it should still be straight forward either way AFAICS.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Tue, Feb 26, 2008 at 12:11:05AM +0300, Nikita V. Youshchenko wrote: While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Fix libetpan-config on Debian to not return libraries that are only related to static linking, and drop libcurl4-gnutls-dev to a Recommends? This looks against how librarieshave been packaged in the past. Which has been discussed many times on this mailing list. In particular, Debian Library Packaging guide [0] This is not a normative document, and is not governed by the procedures for Debian policy updates. Did something change recently? Maybe I missed something? There is nothing in policy that requires library -dev packages to depend on all the other libraries needed for static linking. It happens to be common practice, but that doesn't mean these couldn't be reduced to Recommends as long as dynamic linking continues to work correctly. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 11:48:21PM +0300, Nikita V. Youshchenko wrote: While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Just trim -lcurl from libetpan-config's output and remove the dependency altogether. Obviously, don't do this if libetpan's reverse deps *need* to build with -lcurl (which is unlikely) And what if somebody will try to link statically? Playing devil's advocate: Why would we want to support static linking, when dynamic linking works perfectly well? Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). I stopped providing static libraries in all my library packages quite a while back. No one used them, and they were just needless bloat. I can't say I would be upset if we dropped all the static libraries from the entire archive--is there actually a real world requirement for them in 2008? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
Roger Leigh [EMAIL PROTECTED] writes: I stopped providing static libraries in all my library packages quite a while back. No one used them, and they were just needless bloat. I can't say I would be upset if we dropped all the static libraries from the entire archive--is there actually a real world requirement for them in 2008? MIT Kerberos upstream has dropped support for static linking because of their new plugin infrastructure, and while they hope to reintroduce it by popular demand at some point, it's not a high priority. About the only useful purpose for static linking is when distributing client binaries to many systems where one can't use the native package manager and hence can't use real package dependencies. It lets you limit the amount of stuff that the person has to install. I've run into a few cases like that, but usually the real solution is to fix the underlying issues (often political) preventing the use of real packages with package management. It's more of an issue on systems like Solaris that don't have useful package managers. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 09:53:37PM +0100, Julien Cristau wrote: On Mon, Feb 25, 2008 at 23:48:21 +0300, Nikita V. Youshchenko wrote: Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). That's not true, afaik. If you're linking statically, you have to figure out dependencies on your own. Conventionally, library -dev packages do depend on other -dev packages that they require for static linking; and certainly, tools like pkg-config and libtool (and other home-grown foo-config scripts) tend to encourage this behavior. Nowadays, with a proper .pc file I would argue that this could be reduced to a Recommends. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
