rpath and /usr/lib/package directories
Hi, I recently uploaded courierpassd, which wraps some functionality of courier-authlib in the popassd protocol. lintian has been warning me about the use of rpath, about which I posted on debian-mentors. This culminated in the following thread: http://lists.debian.org/debian-mentors/2006/07/msg00221.html Which along with several other related comments motivated me to open bug #378241, asking courier-authlib to move its public libraries to /usr/lib, per Policy 10.2, which would remove the necessity of courierpassd using rpath. Steve Langasek followed up with the bug, wisely decreasing its severety and stating: I think that suggestion in policy is worse than using rpath and that this ought to be revised. With that extended background, here are my two specific requests: 1) It would be really nice if policy said something about rpath. Currently the most official documentation about it which I could find is: http://wiki.debian.org/RpathIssue If rpath is going to be checked for by lintian, then it seems reasonable to me that there be some official documentation explaining Debian's position on the matter. I've currently asked for this in lintian's bug #378054, but perhaps there should be a parallel bug in debian-policy or elsewhere? 2) It would be nice to have some further discussion on Steve's comment regarding the relative merit of using rpath and /usr/lib/package versus moving all shared libraries into /usr/lib. I opened bug #378055 in lintian about this, but given the developments which have taken place since then, it is no longer clear to me what the right thing is for lintian to do. Again, I think that clarification on this is in policy's domain. thanks, Charles -- A beard That's rough And overgrown is better than A chaperone Burma-Shave http://burma-shave.org/jingles/1951/a_beard signature.asc Description: Digital signature
Re: rpath and /usr/lib/package directories
Charles Fry [EMAIL PROTECTED] writes: Hi, I recently uploaded courierpassd, which wraps some functionality of courier-authlib in the popassd protocol. lintian has been warning me about the use of rpath, about which I posted on debian-mentors. This culminated in the following thread: http://lists.debian.org/debian-mentors/2006/07/msg00221.html Which along with several other related comments motivated me to open bug #378241, asking courier-authlib to move its public libraries to /usr/lib, per Policy 10.2, which would remove the necessity of courierpassd using rpath. Steve Langasek followed up with the bug, wisely decreasing its severety and stating: I think that suggestion in policy is worse than using rpath and that this ought to be revised. With that extended background, here are my two specific requests: 1) It would be really nice if policy said something about rpath. Currently the most official documentation about it which I could find is: http://wiki.debian.org/RpathIssue If rpath is going to be checked for by lintian, then it seems reasonable to me that there be some official documentation explaining Debian's position on the matter. I've currently asked for this in lintian's bug #378054, but perhaps there should be a parallel bug in debian-policy or elsewhere? 2) It would be nice to have some further discussion on Steve's comment regarding the relative merit of using rpath and /usr/lib/package versus moving all shared libraries into /usr/lib. I opened bug #378055 in lintian about this, but given the developments which have taken place since then, it is no longer clear to me what the right thing is for lintian to do. Again, I think that clarification on this is in policy's domain. thanks, Charles Please note that this (rpath) prevents automatic multiarch conversion for packages. Instead of a simple post procesing of the deb files a much more complicated change has to be made to change the rpath. It also requires the use of extra -L statements during build. In conclusion /usr/lib/package for shared libraries just makes everybodies live more complicated. MfG Goswin PS: This would affects amd64-libs, ia32-libs and OOo for amd64 if any component uses the /usr/lib/package way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rpath and /usr/lib/package directories
On Sat, Jul 15, 2006 at 07:50:42AM -0400, Charles Fry wrote: 2) It would be nice to have some further discussion on Steve's comment regarding the relative merit of using rpath and /usr/lib/package versus moving all shared libraries into /usr/lib. Uh, that was *not* the recommendation that you were citing from policy, nor was it the one I was suggesting should be overturned. I was responding to the suggestion that rpath was inappropriate, but adding your own directory to /etc/ld.so.conf would be ok. It would not be ok; there *is* no compelling reason for a package to add its own subdirectories to /etc/ld.so.conf. If the libraries are for public consumption, they should be installed to /usr/lib like all the others and share the simple, flat namespace cleanly; if they are not for public consumption, they should be kept in their own subdirectory and a mechanism such as rpath, LD_LIBRARY_PATH in a wrapper script, or dlopen()ing used instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: rpath and /usr/lib/package directories
On Sat, Jul 15, 2006 at 02:25:49PM +0200, Goswin von Brederlow wrote: Please note that this (rpath) prevents automatic multiarch conversion for packages. Instead of a simple post procesing of the deb files a much more complicated change has to be made to change the rpath. It also requires the use of extra -L statements during build. In conclusion /usr/lib/package for shared libraries just makes everybodies live more complicated. Which is no different from all the other mechanisms used for lookups of private modules; they all require source modification for paths to be fixed to allow co-existence in a multiarch environment. The only way through this is to define multiarch-clean paths and encourage their use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#378386: [PROPOSAL] Include the GFDL in the set shipped in /usr/share/common-licenses
Package: debian-policy Version: 3.7.2.1 Severity: wishlist Tags: patch Hello. In [1], Joerg Jaspert initiated discussion about including more licenses in the set of licenses shipped in /usr/share/common-licensed. As part of the discussion I inquired in [2] about the possibility of adding the GFDL to that set, given the number of packages that ship some contents under this license. Since at least one of the Policy editors, namely Manoj Srivastava, agreed in [3] that the GFDL passes the criteria for inclusion, I'm now transforming the mentioned informal discussion into a formal request. [1] http://lists.debian.org/debian-policy/2006/06/msg00100.html [2] http://lists.debian.org/debian-policy/2006/06/msg00109.html [3] http://lists.debian.org/debian-policy/2006/06/msg00206.html Attached is a patch with the possible wording for the change. Also, if somebody wonders as for why the change is not first commited in the base-files package, and let Policy catch up on reality later: as per /usr/share/doc/base-files/FAQ, the base-files has delegated that decision to the Policy editors. I will submit a bug against base-files after an updated debian-policy is uploaded, or this bug marked by pending by one of the editors. Thanks! -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org We learned that the Linux load average rolls over at 1024. And we actually found this out empirically. -- H. Peter Anvin from kernel.org --- ./policy.sgml~ 2006-07-16 00:14:47.0 +0200 +++ ./policy.sgml 2006-07-16 00:17:56.0 +0200 @@ -8618,8 +8618,8 @@ p Packages distributed under the UCB BSD license, the Artistic - license, the GNU GPL, and the GNU LGPL should refer to the - corresponding files + license, the GNU GPL, and the GNU LGPL, or ship documentation + under the GFDL, should refer to the corresponding files underfile/usr/share/common-licenses/file,footnote p For example, @@ -8627,6 +8627,7 @@ file/usr/share/common-licenses/BSD/file, file/usr/share/common-licenses/GPL/file, file/usr/share/common-licenses/LGPL/file, + file/usr/share/common-licenses/GFDL/file, file/usr/share/common-licenses/GPL-2/file, and file/usr/share/common-licenses/LGPL-2.1/file, and so on. /p
Re: rpath and /usr/lib/package directories
Steve Langasek [EMAIL PROTECTED] writes: On Sat, Jul 15, 2006 at 02:25:49PM +0200, Goswin von Brederlow wrote: Please note that this (rpath) prevents automatic multiarch conversion for packages. Instead of a simple post procesing of the deb files a much more complicated change has to be made to change the rpath. It also requires the use of extra -L statements during build. In conclusion /usr/lib/package for shared libraries just makes everybodies live more complicated. Which is no different from all the other mechanisms used for lookups of private modules; they all require source modification for paths to be fixed to allow co-existence in a multiarch environment. The only way through this is to define multiarch-clean paths and encourage their use. I think the case in discussion is not about private modules. I agree that for private modules one is screwed no matter what existing solution is used. Private modules (or plugins) often are listed in a conffile which adds yet another problem. Multi-arch paths for both conffile and plugins is indeed the only sane solution there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
