Re: Dependencies of -dev packages
On Thu, Nov 03, 2005 at 09:07:12AM -0800, Russ Allbery wrote: Like I said, this defeats the entire point of the FHS. What is the entire point of the FHS? If it is to disallow alternative implementations of the same interface to co-exist then the FHS is broken. Fortunately, this is not my reading the of FHS. There are already many examples: libglib-1.2-dev and libglib-2.0-dev provide overlapping interfaces, yet they can be installed together quite nicely. libgnutlsXX-dev provides part of the interface as libssl-dev and they can be installed together. If you claim that this is against the FHS then you are taking away freedom from the users to choose their preferred implementation of a given interface. I'm not saying that using krb5-config is a bad idea. Over time, it's gotten better and better. But most Kerberos-using software does not use that script for a variety of reasons and patching all Debian packages for all of that software to use it is not necessary or particularly desirable in my opinion. But this does not need to happen in an instant. Quick roadmap (might have some glitches): - move the conflicting files (headers, libs) to non-conflicting locations - provide backward-compatibility symlinks using alternatives - tell maintainers that when they for the next time upload a package that Build-Depends: on one KRB5 implementation to add a Build-Conflicts: with the other implementation. This should happen only at the next upload, so noone needs to hurry. - start converting applications (it might be just as easy as setting CPPFLAGS/LDFLAGS in debian/rules, depending on the application) - when enough applications have converted, make the change mandatory - at some time in the future (etch+1, etch+2...) remove the compatibility links Will step 4 take some (a long) time? Sure. But it is not worse nor more complicated than many other transitions (and Debian is quite familiar with big and long-running transitions :-) It defeats the purpose of the FHS, which is to have files in a predictable and consistent location that doesn't require configuring all software that relies on those files with special flags. Face it: many complex software already require such configuration and this will only become more common, not less. Also, the purpose of the FHS should never be to take away freedom from me, an ordinary Debian user, to select _my_ preferred implementation of an interface _regardless_ of what other -dev packages happen to depend on. Doing so would be a violation of the Social Contract, which I beleive is stronger than the FHS. The FHS only says that include files should go under /usr/include, libraries under /usr/lib etc. It does not say that they cannot go into subdirectories (in fact, it even recommends that for complex packages in case of /usr/lib). Also, it nowhere mentions that conflicting versions of some software should not live simultaneously under different subdirectories of /usr/include, /usr/lib etc. Sorry, my mistake. I had thought that luckily all of the Heimdal library names were different than all of the MIT library names, which I believe is almost true *except* for (of course) libkrb5. Well, if you'd be using krb5-config then you could just rename one of them without anyone noticing (the old shared library should remain until all dependent applications are rebuilt, but that's all). Anyway, given the vehemence of your response, I doubt you're willing to be convinced. Yes, I'm quite pissed off when I want to install some -dev package (that I do not even need the Kerberos support of) just for trying it and it wants to remove heimdal-dev in favor of libkrb5-dev while a compilation using heimdal-dev is still running in an other window... Of course, if you have some other solution that unconditionally keeps heimdal-dev installed (and which does not require rebuilding all MIT-dependant -dev packages against Heimdal), I'd be interested. Given that, I'll just say that, as the co-maintainer of the MIT Kerberos package, I will not do what you suggest, and leave it at that (at least in the absence of other arguments that strike me as more persuasive). If you want the package to change, you can try to convince Sam, but I expect he'll have the same objections. Well, the other option for me is to bug every Kerberos-using package to also have a version built against Heimdal, but I'm not quite enthusiastic as except this stupid Conflicts: between the -dev packages I see no technical reason to do so. IMHO flamebait=yes eat-it=no what-if-you-did=reply-off-list Although this is not a _technical_ reason, it would still be useful to have both a MIT and a Heimdal-dependent version of every KRB5-using application. So if the USA goes insane again about crypto stuff, we will not be left without a working tested KRB5 implementation. /IMHO Gabor -- - MTA SZTAKI
Re: Dependencies of -dev packages
On Mon, Oct 31, 2005 at 11:15:35PM -0800, Russ Allbery wrote: Speaking as a co-maintainer of libkrb5-dev, no, this Conflicts assumes that the two packages, er, conflict. Namely, they provide identically-named include files which define different ways of implementing roughly the same API. I'd love to have heimdal-dev and libkrb5-dev peacefully coexist since I personally use both, but since they both implement the same API, this is rather difficult to do. Having the same API is not a problem as long as I can select (using appropriate -I and -L options) which one do I want. Please note that using pbuilder works around this issue fairly well for building Debian packages, although I realize that this is far from solving every application. But that does not work well in a multi-user environment. Requiring every user to have a separate pbuilder environment so they can use their preferred Kerberos implementation requires a lot of extra disk space, I/O bandwidth, memory and CPU power. Also, pbuilder might not be that useful for people working on software that is not Debianized. I don't consider this to be a good solution. #include krb5.h is part of the API, and forcing all packages that want to build with Kerberos to use special compiler flags to find include files in non-standard locations seems to me to defeat the entire point of the FHS. This is nonsense. People using other OSes routinely build software at non-standard locations and they do not have any API issues at all. Furthermore, any Kerberos-using application should already use krb5-config to determine the neccessary compiler and linker flags, otherwise the application is already buggy as it will not build correctly on many non-Linux systems where Kerberos is not installed at a system location. Also, I do not see any FHS issues here. Heimdal installing headers under /usr/include/heimdal-krb5 (and .so links under /usr/lib/heimdal-krb5) while MIT Kerberos installing headers under /usr/include/mit-krb5 (and .so links under /usr/lib/mit-krb5) is fully FHS-compliant. (I didn't think separating the libraries was necessary; don't they use non-conflicting names already?) Which separation do you think of? Both heimdal-dev and libkrb5-dev contain the /usr/lib/libkrb5.so symlink, so they do conflict unless that link is moved to some other place. The only solution that seems feasible to me would be using alternatives for all of the conflicting header files, and that solution doesn't exactly fill me with glee. No. As I said krb5-config is already part of the Kerberos build interface so you only need alternatives for krb5-config. I would also question whether running update-alternatives is really that much easier than simply installing the other -dev package and letting aptitude do its thing. What do you mean by letting aptitude do its thing? aptitude would _remove_ the other -dev package and that is _exactly_ what I have problem with. 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: Dependencies of -dev packages
Gabor Gombas [EMAIL PROTECTED] writes: On Mon, Oct 31, 2005 at 11:15:35PM -0800, Russ Allbery wrote: I don't consider this to be a good solution. #include krb5.h is part of the API, and forcing all packages that want to build with Kerberos to use special compiler flags to find include files in non-standard locations seems to me to defeat the entire point of the FHS. This is nonsense. People using other OSes routinely build software at non-standard locations and they do not have any API issues at all. Like I said, this defeats the entire point of the FHS. Furthermore, any Kerberos-using application should already use krb5-config to determine the neccessary compiler and linker flags, otherwise the application is already buggy as it will not build correctly on many non-Linux systems where Kerberos is not installed at a system location. I maintain lots of Kerberos-using applications, none of which use krb5-config, and all of which build fine on non-Linux systems where Kerberos is not installed at the system location. The *-config scripts are not always a great idea; among other problems, they're something of an all or nothing affair and it's difficult to work around bugs or inadequate information in those scripts if you're using them. I'm not saying that using krb5-config is a bad idea. Over time, it's gotten better and better. But most Kerberos-using software does not use that script for a variety of reasons and patching all Debian packages for all of that software to use it is not necessary or particularly desirable in my opinion. Also, I do not see any FHS issues here. Heimdal installing headers under /usr/include/heimdal-krb5 (and .so links under /usr/lib/heimdal-krb5) while MIT Kerberos installing headers under /usr/include/mit-krb5 (and .so links under /usr/lib/mit-krb5) is fully FHS-compliant. It defeats the purpose of the FHS, which is to have files in a predictable and consistent location that doesn't require configuring all software that relies on those files with special flags. (I didn't think separating the libraries was necessary; don't they use non-conflicting names already?) Which separation do you think of? Both heimdal-dev and libkrb5-dev contain the /usr/lib/libkrb5.so symlink, so they do conflict unless that link is moved to some other place. Sorry, my mistake. I had thought that luckily all of the Heimdal library names were different than all of the MIT library names, which I believe is almost true *except* for (of course) libkrb5. Anyway, given the vehemence of your response, I doubt you're willing to be convinced. Given that, I'll just say that, as the co-maintainer of the MIT Kerberos package, I will not do what you suggest, and leave it at that (at least in the absence of other arguments that strike me as more persuasive). If you want the package to change, you can try to convince Sam, but I expect he'll have the same objections. -- 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: Dependencies of -dev packages
Gabor Gombas [EMAIL PROTECTED] writes: libkrb5-dev Conflicts: heimdal-dev == The problem here is that this Conflicts: assumes that the system has just one user, which is simply not true. Speaking as a co-maintainer of libkrb5-dev, no, this Conflicts assumes that the two packages, er, conflict. Namely, they provide identically-named include files which define different ways of implementing roughly the same API. I'd love to have heimdal-dev and libkrb5-dev peacefully coexist since I personally use both, but since they both implement the same API, this is rather difficult to do. Please note that using pbuilder works around this issue fairly well for building Debian packages, although I realize that this is far from solving every application. pkg-config comes handy again. If every package provides a .pc file, then conflicting libraries and headers can simply be moved to separate directories (/usr/lib/heimdal, /usr/lib/mit-krb5, /usr/include/heimdal, /usr/include/mit-krb5) and can peacefully coexist. I don't consider this to be a good solution. #include krb5.h is part of the API, and forcing all packages that want to build with Kerberos to use special compiler flags to find include files in non-standard locations seems to me to defeat the entire point of the FHS. (I didn't think separating the libraries was necessary; don't they use non-conflicting names already?) The only solution that seems feasible to me would be using alternatives for all of the conflicting header files, and that solution doesn't exactly fill me with glee. I would also question whether running update-alternatives is really that much easier than simply installing the other -dev package and letting aptitude do its thing. (Note that there are other conflicts between MIT Kerberos and Heimdal that aren't really necessary, though, and I *would* find it reasonable to use alternatives for the command-line utilities like kinit. This is something that's on my long-term to-do list, and if one of the Heimdal maintainers wanted to work with me on that, we could probably make many of those conflicts go away.) -- 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: Dependencies of -dev packages
On Tue, Oct 25, 2005 at 07:15:29PM +0200, Kurt Roeckx wrote: Then I guess it's either not used properly most of the time, or hard they make it hard to use it properly. That's right. Requres.private: is supported only since pkg-config-0.18, and there are not many packages making use of it yet. I think the wast majority of nowaday's Requires: should be turned to Requires.private:. This might be a good target for a BSP (very easy to fix, low chance to break anything). (for example, by directly referencing symbols from libb in a's header files). In this case, you _do_ need to link with libb explicitely, shared library dependencies won't help you. The liba is not designed properly, it's shouldn't expose that it's using libb. Extreme example: it is possible that public headers from a reference symbols from b, but liba itself does not use any symbols from libb, therefore it does not depend (in the DT_NEEDED sense) on libb at all. Which is completly broken. Those statements I can agree with, but there are a lot of broken software out there. 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: Dependencies of -dev packages
On Mon, Oct 24, 2005 at 07:55:25PM +0200, Kurt Roeckx wrote: $ pkg-config --libs a -la -lb ^^^ It should not link to libb if you only request it to link to liba. liba should have a DT_NEEDED for libb, and the linker should find the symbols liba needs from libb itself. No. Using Requires: instead of Requires.private: means that a's API exposes the dependency on b (for example, by directly referencing symbols from libb in a's header files). In this case, you _do_ need to link with libb explicitely, shared library dependencies won't help you. Extreme example: it is possible that public headers from a reference symbols from b, but liba itself does not use any symbols from libb, therefore it does not depend (in the DT_NEEDED sense) on libb at all. 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: Dependencies of -dev packages
On Tue, Oct 25, 2005 at 04:29:20PM +0200, Gabor Gombas wrote: On Mon, Oct 24, 2005 at 07:55:25PM +0200, Kurt Roeckx wrote: $ pkg-config --libs a -la -lb ^^^ It should not link to libb if you only request it to link to liba. liba should have a DT_NEEDED for libb, and the linker should find the symbols liba needs from libb itself. No. Using Requires: instead of Requires.private: means that a's API exposes the dependency on b Then I guess it's either not used properly most of the time, or hard they make it hard to use it properly. (for example, by directly referencing symbols from libb in a's header files). In this case, you _do_ need to link with libb explicitely, shared library dependencies won't help you. The liba is not designed properly, it's shouldn't expose that it's using libb. Extreme example: it is possible that public headers from a reference symbols from b, but liba itself does not use any symbols from libb, therefore it does not depend (in the DT_NEEDED sense) on libb at all. Which is completly broken. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Fri, Oct 21, 2005 at 10:24:11PM +0200, Goswin von Brederlow wrote: The problem is that pc files are architecture dependent. With multiarch there will be /usr/lib/i486-linux-gnu/glib.pc /usr/lib/x86_64-linux-gnu/glib.pc Well, pkg-config already places .pc files under /usr/lib instead of /usr/share, so the intention is clearly that .pc files _are_ arch-dependent. The nice thing is that users won't even notice if we change the default search path from /usr/lib/pkgconfig to /usr/lib/arch/pkgconfig (the existing .pc files of course have to be relocated, but that will be part of the multiarch transition). Depending on the -m32/-m64 switch for gcc only one of them is valid. pkg-config is usually run by configure, way before gcc is invoked. So we need a way to tell pkg-config the desired architecture. The simplest thing is to install a wrapper that sets PKG_CONFIG_LIBDIR before calling the real pkg-config. 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: Dependencies of -dev packages
On Fri, Oct 21, 2005 at 07:15:38PM +0200, Kurt Roeckx wrote: 3D Pretty please don't suggest that unless you first fix pkg-config. It's always linking in the libraries required for static linking even if you don't request it. See for instance bug #254290, which was closed, but didn't really do what the original patch did. What needs fixing? I did not have time to guess what the completely undocumented patch in #254290 does, so I did a little experiment: a.pc: prefix=/usr Name: a Description: a Version: 1.0 Requires: b Requires.private: c Libs: -la b.pc: prefix=/usr Name: b Description: b Version: 1.0 Libs: -lb Libs.private: -lbstatic c.pc: prefix=/usr Name: c Description: c Version: 1.0 Libs: -lc Libs.private: -lcstatic $ pkg-config --libs a -la -lb $ pkg-config --libs --static a -la -lc -lcstatic -lb -lbstatic It seems to work perfectly. Of course the problem might be that .pc files installed on my desktop currently do not seem to use either Requires.private or Libs.private yet. 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: Dependencies of -dev packages
On Fri, Oct 21, 2005 at 02:15:28AM +0100, Darren Salt wrote: I can see potential problems with that last part regarding upstream developers whose software happens to depend on packages for which pkg-config support remains Debian-specific because upstream doesn't accept the patch. It's possible that the Debian-specific nature of this support may simply not be noticed until bug reports start coming in from users of other distributions... Well, the only problem I can see is auto-detection (configure etc.) behaving differently. But if we follow the try pkg-config first, if that failed, fall back to what detection technique we have used before approach, then we cannot be more broken than current upstream is. On the other hand, autodetection is never perfect and bugs always happen. But if we can agree that the general direction is good and worth pursuing then we can fix bugs as they are found on the way. 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: Dependencies of -dev packages
On Mon, 24 Oct 2005, Gabor Gombas wrote: On Fri, Oct 21, 2005 at 02:15:28AM +0100, Darren Salt wrote: I can see potential problems with that last part regarding upstream developers whose software happens to depend on packages for which pkg-config support remains Debian-specific because upstream doesn't accept the patch. It's possible that the Debian-specific nature of this support may simply not be noticed until bug reports start coming in from users of other distributions... Well, the only problem I can see is auto-detection (configure etc.) May I humbly remind people that allowing any sort of arch autodetection in a Debian package build *IS* *A* *BUG*. dpkg-architecture knows the arch. You have to use that arch. It is that simple. People packaging stuff that uses autoconf, should imediatelly install autotools-dev and read the package README. It teaches how to feed dpkg-architecture output to autoconf correctly. On the other hand, autodetection is never perfect and bugs always happen. But if we can agree that the general direction is good and worth The fact that it is attempted at all is the bug. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Mon, Oct 24, 2005 at 10:36:08AM -0200, Henrique de Moraes Holschuh wrote: May I humbly remind people that allowing any sort of arch autodetection in a Debian package build *IS* *A* *BUG*. Who talked about _arch_ autodetection? I think the discussion was about packages that previously only tried detecting the presence of certain headers or library functions should now use pkg-config, and that may only work with Debian-provided .pc files until changes are accepted back upstream. Arch _selection_ is an orthogonal problem. And no, just saying dpkg-architecture is not enough, because with multiarch, dpkg-architecture still has to know which architecture does the user want to build for, and that selection must be propagated all way down (e.g. by adding the appropriate -m32/-m64 switch to gcc). On the other hand, autodetection is never perfect and bugs always happen. But if we can agree that the general direction is good and worth The fact that it is attempted at all is the bug. So you call the existence of autotools a bug? I welcome you to write a moderately complex application that builds both on Linux and AIX without any autodetection and without requiring the user to specify a plethora of options... 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: Dependencies of -dev packages
On Mon, 24 Oct 2005, Gabor Gombas wrote: Who talked about _arch_ autodetection? I think the discussion was about Sorry, my bad. I thought that mentioning arch and configure and auto-detection in the same post meant the kind of runtime arch autodetection buggy debian packages (and non-buggy upstream packages) let autotools do. I.e. running config.guess. That said, it is sort of on-topic anyway. Can pkg-config be told which arch to build to? If it doesn't, it is high time to fix this, and it would fix the problem of getting .pc files to be installed to the right place, too. Who cares if that means the pkg-config binary we ship will have to be a great deal more intelligent than the pkg-config other distros need? It would still work, and it wouldn't break cross-distro compatibility, either. Unless packages ship the pkg-config binary itself. Even then, the Debian mode could be dependent on dpkg-architecture existing or somesuch, so people could still use Debian as upstream developers without hassle. Arch _selection_ is an orthogonal problem. And no, just saying dpkg-architecture is not enough, because with multiarch, dpkg-architecture still has to know which architecture does the user want to build for, and that selection must be propagated all way down (e.g. by adding the appropriate -m32/-m64 switch to gcc). That is a system-wide problem, dpkg-* is no exception there. Debian utilities should ask dpkg-architecture about the running arch, probably (unless we export all the dpkg-architecture data to the environment and make that non-optional). Debian builds would then have to do whatever is needed to get the tools they use (autoconf, pkgconfig, etc) to build for the right arch. And the tools must be enhanced to allow the Debian build scripts to force which arch they are working for, if they don't have such features yet (autoconf does, and it actually works since 2.52 or thereabouts). So you call the existence of autotools a bug? I welcome you to write a moderately complex application that builds both on Linux and AIX without any autodetection and without requiring the user to specify a plethora of options... Go read the autotools-dev README. Take the time to notice who is the autotools-dev maintainer since day one, and who wrote that README. That WILL answer your question about my position re. autotools, AND about my position about autodetection of stuff, AND also about arch autodetection (which are two different things). If it doesn't, let me know. To make things more clear: autodetection of libraries was not what I was complaining about. It was about runtime arch autodetection as done by autoconf and the like in package builds, which AFAIK is against Debian policy. THAT said, package maintainers better know exactly how to make sure no feature autodetection by autoconf will get them with their pants down. It should only happen because they wanted it to, not because they lacked build-deps or build-conflicts. But THIS is a topic for another thread. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
Gabor Gombas [EMAIL PROTECTED] writes: On Fri, Oct 21, 2005 at 10:24:11PM +0200, Goswin von Brederlow wrote: The problem is that pc files are architecture dependent. With multiarch there will be /usr/lib/i486-linux-gnu/glib.pc /usr/lib/x86_64-linux-gnu/glib.pc Well, pkg-config already places .pc files under /usr/lib instead of /usr/share, so the intention is clearly that .pc files _are_ arch-dependent. The nice thing is that users won't even notice if we change the default search path from /usr/lib/pkgconfig to /usr/lib/arch/pkgconfig (the existing .pc files of course have to be relocated, but that will be part of the multiarch transition). Depending on the -m32/-m64 switch for gcc only one of them is valid. pkg-config is usually run by configure, way before gcc is invoked. So we need a way to tell pkg-config the desired architecture. The simplest thing is to install a wrapper that sets PKG_CONFIG_LIBDIR before calling the real pkg-config. Gabor That is indeed the problem. But how would a wraper help? You still have to somehow tell the wraper if gcc will later be invoked with -m32 or -m64. Only solutions I see sofar is to either pass the gnu tripple to pkgconfig, to have configure set some environment variable or to include some variable in all paths that gcc later fills in. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Mon, Oct 24, 2005 at 12:37:41PM -0200, Henrique de Moraes Holschuh wrote: That said, it is sort of on-topic anyway. Can pkg-config be told which arch to build to? If it doesn't, it is high time to fix this, and it would fix the problem of getting .pc files to be installed to the right place, too. Not yet. The simplest workaround is to create a wrapper around pkg-config that sets PKG_CONFIG_LIBDIR based on the selected architecture. Later we should add a --arch to pkg-config. Who cares if that means the pkg-config binary we ship will have to be a great deal more intelligent than the pkg-config other distros need? It would still work, and it wouldn't break cross-distro compatibility, either. I think as long as the installed .pc files are backward-compatible it is OK to introduce new features in Debian first and try to push the changes upstream later. Unless packages ship the pkg-config binary itself. Even then, the Debian mode could be dependent on dpkg-architecture existing or somesuch, so people could still use Debian as upstream developers without hassle. I do not think pkg-config should call dpkg-architecture. Instead I think of something like this: - the user decides the architecture (if we are building a Debian package, then by calling dpkg-architecture) - the selected architecture is passed to the build system (--host= argument to 'configure', parameter to 'make' etc.) - the build system passes down the information to pkg-config This way there is a single point where the user can decide the architecture (note that not all users are building Debian packages, and not all users want to build for the default architecture, so dpkg-architecture should not be mandatory). Debian utilities should ask dpkg-architecture about the running arch, probably (unless we export all the dpkg-architecture data to the environment and make that non-optional). For Debian utilities, this is reasonable. Debian builds would then have to do whatever is needed to get the tools they use (autoconf, pkgconfig, etc) to build for the right arch. And the tools must be enhanced to allow the Debian build scripts to force which arch they are working for, if they don't have such features yet (autoconf does, and it actually works since 2.52 or thereabouts). Yep. Multiarch is not common yet so there will definitely bugs and missing features in various tools, but that cannot be helped. THAT said, package maintainers better know exactly how to make sure no feature autodetection by autoconf will get them with their pants down. It should only happen because they wanted it to, not because they lacked build-deps or build-conflicts. But THIS is a topic for another thread. Don't forget that threre are regular users building their own stuff under their home directories. Autodetection is really handy to make use whatever is installed on the current system and not to worry about optional components having missing dependencies. I think many of the past present problems with autotools (like the -rpath issue, or too much dependencies in .la files) come from the fact that autotools were created with these users in mind and little thought was given for distribution-makers. 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: Dependencies of -dev packages
I demand that Gabor Gombas may or may not have written... On Fri, Oct 21, 2005 at 02:15:28AM +0100, Darren Salt wrote: I can see potential problems with that last part regarding upstream developers whose software happens to depend on packages for which pkg-config support remains Debian-specific because upstream doesn't accept the patch. It's possible that the Debian-specific nature of this support may simply not be noticed until bug reports start coming in from users of other distributions... Well, the only problem I can see is auto-detection (configure etc.) behaving differently. But if we follow the try pkg-config first, if that failed, fall back to what detection technique we have used before approach, then we cannot be more broken than current upstream is. Providing suitable autoconf macros will help, at least with release tarballs; you still potentially have the problem with CVS (unless the macros are duplicated in the package source, typically via inclusion in an m4 directory). On the other hand, autodetection is never perfect and bugs always happen. But if we can agree that the general direction is good and worth pursuing then we can fix bugs as they are found on the way. I'd say that it is, on condition that these changes are pushed upstream reasonably quickly. -- | Darren Salt | linux (or ds) at | nr. Ashington, | sarge,| youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | I don't ask for much, just untold riches... This is a test tagline; please ignore. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Mon, Oct 24, 2005 at 07:13:02PM +0200, Goswin von Brederlow wrote: That is indeed the problem. But how would a wraper help? You still have to somehow tell the wraper if gcc will later be invoked with -m32 or -m64. Whatever build system you use, there must be some logic somewhere to decide what arcitecture to build for, and what other settings that architecture needs. This logic may be in the user (by explicitely setting PKG_CONFIG_LIBDIR and CFLAGS) or some script that decides that if we are running on x86_64 and we want to build for ix86 then we should add -m32 to CFLAGS. This component should be extended to handle pkg-config as well. (I'm carefully trying to avoid being autoconf-centric here :-) Only solutions I see sofar is to either pass the gnu tripple to pkgconfig, to have configure set some environment variable or to include some variable in all paths that gcc later fills in. Yes, the easiest solution is just to pass the target system tripple to pkg-config. Support for this can be added to /usr/share/aclocal/pkg.m4 so autoconf-using packages can benefit from it automatically (after re-running aclocal autoconf, of course). An idea independent of pkg-config: do we have an utility that takes a system tripple and outputs the gcc flags (-m32/-m64) needed for building for that arch? That would be useful to verify that the value given for --host= is consistent with the value of CFLAGS/CXXFLAGS/FFLAGS. 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: Dependencies of -dev packages
On Mon, Oct 24, 2005 at 02:03:51PM +0200, Gabor Gombas wrote: On Fri, Oct 21, 2005 at 07:15:38PM +0200, Kurt Roeckx wrote: 3D Pretty please don't suggest that unless you first fix pkg-config. It's always linking in the libraries required for static linking even if you don't request it. See for instance bug #254290, which was closed, but didn't really do what the original patch did. What needs fixing? I did not have time to guess what the completely undocumented patch in #254290 does, so I did a little experiment: $ pkg-config --libs a -la -lb ^^^ It should not link to libb if you only request it to link to liba. liba should have a DT_NEEDED for libb, and the linker should find the symbols liba needs from libb itself. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Mon, 24 Oct 2005, Gabor Gombas wrote: Unless packages ship the pkg-config binary itself. Even then, the Debian mode could be dependent on dpkg-architecture existing or somesuch, so people could still use Debian as upstream developers without hassle. I do not think pkg-config should call dpkg-architecture. Instead I think of something like this: It doesn't need to. It needs to have a way to be told which arch to use. *Debian* build scripts need to make sure that they tell pkg-config to use the arch given by dpkg-architecture. We shall see which way is better, I'd much rather do it autoconf style, which seems to be what you prefer (the --arch option). - the selected architecture is passed to the build system (--host= argument to 'configure', parameter to 'make' etc.) Is not --host only. Just for the record. autotools-dev README has the full details. But otherwise, I agre with you. Don't forget that threre are regular users building their own stuff I never do. Nor do I forget about upstream development done in Debian boxes. I think many of the past present problems with autotools (like the -rpath issue, or too much dependencies in .la files) come from the fact Those are mostly libtool issues, and libtool is a slow moving beast :( autoconf isn't, but people refuse to fix their build systems or upgrade to newest versions, so there will be a lot of shouting soon (we may have to outlaw old libtool crap in Debian, and that immediately means all that bitrot needs to be ported to latest autoconf (for libtool), and if it uses automake, to a recent automake as well (because old automake does not talk to libtool or new autoconf either). that autotools were created with these users in mind and little thought was given for distribution-makers. That is certainly true about libtool. Not so for automake or autoconf. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Mon, 24 Oct 2005, Kurt Roeckx wrote: On Mon, Oct 24, 2005 at 02:03:51PM +0200, Gabor Gombas wrote: On Fri, Oct 21, 2005 at 07:15:38PM +0200, Kurt Roeckx wrote: Pretty please don't suggest that unless you first fix pkg-config. It's always linking in the libraries required for static linking even if you don't request it. See for instance bug #254290, which was closed, but didn't really do what the original patch did. What needs fixing? I did not have time to guess what the completely undocumented patch in #254290 does, so I did a little experiment: $ pkg-config --libs a -la -lb ^^^ It should not link to libb if you only request it to link to liba. liba should have a DT_NEEDED for libb, and the linker should find the symbols liba needs from libb itself. For dynamic linkage. Static, AFAIK, requires both libs. And here lies the utter braindamage in pkg-config. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Mon, Oct 24, 2005 at 05:20:16PM -0200, Henrique de Moraes Holschuh wrote: $ pkg-config --libs a -la -lb ^^^ It should not link to libb if you only request it to link to liba. liba should have a DT_NEEDED for libb, and the linker should find the symbols liba needs from libb itself. For dynamic linkage. Static, AFAIK, requires both libs. And here lies the utter braindamage in pkg-config. And pkg-config has a --static option for that, that adds more libs, see his example. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
Gabor Gombas [EMAIL PROTECTED] writes: On Mon, Oct 24, 2005 at 07:13:02PM +0200, Goswin von Brederlow wrote: That is indeed the problem. But how would a wraper help? You still have to somehow tell the wraper if gcc will later be invoked with -m32 or -m64. Whatever build system you use, there must be some logic somewhere to decide what arcitecture to build for, and what other settings that architecture needs. This logic may be in the user (by explicitely setting PKG_CONFIG_LIBDIR and CFLAGS) or some script that decides that if we are running on x86_64 and we want to build for ix86 then we should add -m32 to CFLAGS. This component should be extended to handle pkg-config as well. (I'm carefully trying to avoid being autoconf-centric here :-) Only solutions I see sofar is to either pass the gnu tripple to pkgconfig, to have configure set some environment variable or to include some variable in all paths that gcc later fills in. Yes, the easiest solution is just to pass the target system tripple to pkg-config. Support for this can be added to /usr/share/aclocal/pkg.m4 so autoconf-using packages can benefit from it automatically (after re-running aclocal autoconf, of course). An idea independent of pkg-config: do we have an utility that takes a system tripple and outputs the gcc flags (-m32/-m64) needed for building for that arch? That would be useful to verify that the value given for --host= is consistent with the value of CFLAGS/CXXFLAGS/FFLAGS. dpkg-libinfo or dpkg-multiarch both implement that with different interfaces. Both have been tested but not uploaded to sid yet. The later is more flexible and I will probably upload it at some point. dpkg-multiarch takes the debian arch that we build debs for (e.g x86_64-linux-gnu for amd64) and the target arch the binary code is for (e.g. i486-linux-gnu for 32bit code on amd64) and then outputs CFLAGS, LIBDIR, ... appropriate for that specific combination in the same manner dpkg-architecture work. Both deb arch and code arch default to the arch from dpkg-architecture. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Thu, Oct 20, 2005 at 09:16:01PM +0200, Gabor Gombas wrote: - Make pkg-config mandatory. pkg-config can already handle the case that different libraries are needed for static and shared linking. pkg-config also helps the second problem (conflicting -dev packages), see below Pretty please don't suggest that unless you first fix pkg-config. It's always linking in the libraries required for static linking even if you don't request it. See for instance bug #254290, which was closed, but didn't really do what the original patch did. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
On Thu, Oct 20, 2005 at 09:16:01PM +0200, Gabor Gombas wrote: - Make pkg-config mandatory. pkg-config can already handle the case that different libraries are needed for static and shared linking. pkg-config also helps the second problem (conflicting -dev packages), see below Did pkg-config solve the multiarch problem? The problem is that pc files are architecture dependent. With multiarch there will be /usr/lib/i486-linux-gnu/glib.pc /usr/lib/x86_64-linux-gnu/glib.pc Depending on the -m32/-m64 switch for gcc only one of them is valid. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies of -dev packages
I demand that Gabor Gombas may or may not have written... [snip] So I propose a different solution, which is not perfect, but is better than the current situation: - -dev packages should only Depend: on other -dev packages neccessary for shared linking - -dev packages should Recommend: any other -dev packages that are neccessary for static linking - Make pkg-config mandatory. pkg-config can already handle the case that different libraries are needed for static and shared linking. I can see potential problems with that last part regarding upstream developers whose software happens to depend on packages for which pkg-config support remains Debian-specific because upstream doesn't accept the patch. It's possible that the Debian-specific nature of this support may simply not be noticed until bug reports start coming in from users of other distributions... [snip] -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Retrocomputing: a PC card in a Risc PC Would it help if I got out and pushed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on -dev packages
Andrew == Andrew Suffield [EMAIL PROTECTED] writes: Andrew Recommends and Suggests are not considered when installing Andrew build-dependencies. And packages aren't supposed to be built staticly either. Packages that do build staticly could explicitly Build-Depend on whatever they require. Regardless, I've had my question (partially) answered; unless Debian generally moves to versioned symbols, more conversation is moot. -- Stephen And what do we burn apart from witches?... More witches!
Re: Dependencies on -dev packages
On 03 Sep 2002 11:58:10 -0700 Stephen Zander [EMAIL PROTECTED] wrote: What is the thinking behind always requiring libfoo-dev to depend on libbar-dev when libfoo depends on libbar? I understand the need when /usr/include/foo.h contains #include bar.h So that libbar-dev can conflict with packages that libbar is incompatible with at run-time, so that other shared libraries that are incompatible do not get loaded in the same shared namespace. Google, libpkg-guide. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Dependencies on -dev packages
On Tue, Sep 03, 2002 at 11:58:10 -0700, Stephen Zander wrote: but if libfoo opaquely wraps libbar, why have libfoo-dev depend on libbar-dev? How opaque is that opaque when considering the case of linking against a library statically? Ray -- The problem with the global village is all the global village idiots. Paul Ginsparg
Re: Dependencies on -dev packages
Stephen Zander [EMAIL PROTECTED] writes: What is the thinking behind always requiring libfoo-dev to depend on libbar-dev when libfoo depends on libbar? I understand the need when /usr/include/foo.h contains #include bar.h but if libfoo opaquely wraps libbar, why have libfoo-dev depend on libbar-dev? Do you have a case where theres no #include bar.h? Then you would just build-depend on libbar-dev. If it works 100% without there is no need to depend. MfG Goswin
Re: Dependencies on -dev packages
Ray == J H M Dassen J.H.M. writes: Ray How opaque is that opaque when considering the case of Ray linking against a library statically? That need might reasonably be met with a Recommends: or Suggests: -- Stephen To Republicans, limited government means not assisting people they would sooner see shoveled into mass graves. -- Kenneth R. Kahn
Re: Dependencies on -dev packages
On Tue, Sep 03, 2002 at 01:57:33PM -0700, Stephen Zander wrote: Ray == J H M Dassen J.H.M. writes: Ray How opaque is that opaque when considering the case of Ray linking against a library statically? That need might reasonably be met with a Recommends: or Suggests: Recommends and Suggests are not considered when installing build-dependencies. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpux4IfEZvF6.pgp Description: PGP signature
Re: Dependencies on -dev packages
On Tue, 03 Sep 2002, Goswin Brederlow wrote: Stephen Zander [EMAIL PROTECTED] writes: What is the thinking behind always requiring libfoo-dev to depend on libbar-dev when libfoo depends on libbar? I understand the need when The lack of symbol versioning, about 90% of the time. but if libfoo opaquely wraps libbar, why have libfoo-dev depend on libbar-dev? It only opaquely wraps libbar if it is compiled statically. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Dependencies on -dev packages
I wrote a longer response to this but then thought about what you wrote a bit more and deleted it. Henrique == Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: Henrique The lack of symbol versioning, about 90% of the time. Then why not mandate symbol versioning instead; that would be a much lighter-weight solution IMHO. -- Stephen You will be a large breasted porno star in your next life - Chinese Fortune Cookie
Re: Dependencies on -dev packages
On Tue, 03 Sep 2002, Stephen Zander wrote: I wrote a longer response to this but then thought about what you wrote a bit more and deleted it. Henrique == Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: Henrique The lack of symbol versioning, about 90% of the time. Then why not mandate symbol versioning instead; that would be a much lighter-weight solution IMHO. I would *love* to have Debian mandate symbol versioning. But it is extremely unforgiving of soname fuckups (one usually uses the soname as the versioning, unless one knows much better AND one is upstream), so it is not as easy to get people to adopt it as I'd like. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
