Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
On Thu, May 08, 2014 at 01:20:42PM -0700, Jonathan Nieder wrote: Bill Allombert wrote: On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote: FWIW I don't mind if you tweak the wording. Unfortunately it's not just qual = 32 or 64[1]. Luckily the only ones that would be relevant the way Debian uses qual are qual = 32 (mips, tilegx) qual = 64 (mips, powerpc, x86) qual = x32 (x86) However the FHS version mandated by policy does not include libx32, so it could be argued that there is no need for a FHS exception for libx32. If I understand correctly then alas, no --- the FHS meaning of qual is open ended. When it describes lib32 and lib64 it says The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. This is a refinement of the general rules for /libqual and /usr/libqual. In other words, there are rules elsewhere in the document about how libqual works generally for lib32, lib64, libx32, libxyzzy, or whatever, and here are the more specific rules that govern lib, lib32, and lib64 on PPC64, s390x, sparc64, AMD64, and IA64. How about the following (text as before, except a parenthesized phrase added)? The requirement for /usr/local/libqual to exist if /libqual or /usr/libqual exists (where libqual is a variant of lib such as lib32 or lib64) is removed. such as should cover any future lib directories. I took the liberty to apply your wording (also I fixed a minor typo in the SGML entity, and I added your name in the changelog) Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
On Thu, May 08, 2014 at 01:20:42PM -0700, Jonathan Nieder wrote: Bill Allombert wrote: On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote: FWIW I don't mind if you tweak the wording. Unfortunately it's not just qual = 32 or 64[1]. Luckily the only ones that would be relevant the way Debian uses qual are qual = 32 (mips, tilegx) qual = 64 (mips, powerpc, x86) qual = x32 (x86) However the FHS version mandated by policy does not include libx32, so it could be argued that there is no need for a FHS exception for libx32. If I understand correctly then alas, no --- the FHS meaning of qual is open ended. When it describes lib32 and lib64 it says The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. This is a refinement of the general rules for /libqual and /usr/libqual. In other words, there are rules elsewhere in the document about how libqual works generally for lib32, lib64, libx32, libxyzzy, or whatever, and here are the more specific rules that govern lib, lib32, and lib64 on PPC64, s390x, sparc64, AMD64, and IA64. How about the following (text as before, except a parenthesized phrase added)? The requirement for /usr/local/libqual to exist if /libqual or /usr/libqual exists (where libqual is a variant of lib such as lib32 or lib64) is removed. such as should cover any future lib directories. This seems good. THe FHS never formally define what qual means actually. Adding this allow the reader to understand what the exception is about. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
]] Aurelien Jarno How can we progress on this bug? We now have bugs #720777, #720778 and #720780 which ask for /usr/libqual to be created if /libqual exists. It's something that can be implemented, but before doing so, I would like to know if a decision has been taken wrt the policy. I think the whole libqual thing should be avoided and we should nack it for any new ports. Ideally, we should also try to get ourselves out of the hole we've dug ourselves into. I don't see anybody being against relaxing the requirement for /usr/local/libqual to exist, so we're presumably blocked on more seconds. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
On Thu, May 08, 2014 at 09:08:58AM +0200, Tollef Fog Heen wrote: ]] Aurelien Jarno How can we progress on this bug? We now have bugs #720777, #720778 and #720780 which ask for /usr/libqual to be created if /libqual exists. It's something that can be implemented, but before doing so, I would like to know if a decision has been taken wrt the policy. I think the whole libqual thing should be avoided and we should nack it for any new ports. Ideally, we should also try to get ourselves out of the hole we've dug ourselves into. Unfortunately given we still want to keep multilib compilers in the archive, we need to provide foreign binaries, and thus install them in libqual. The policy clearly states that a foreign binary should not be installed in the multiarch path, and that's really a good thing given how much pain multilib packages are already (especially when people start to install libc6-dev-amd64:i386 on an amd64 system or things like that). Currently for being able to build i386 binaries on an amd64 system, you need to install libc6-i386:amd64, usually used in addition to libc6:i386. This is a pain from the glibc side as we have to handle the fact that they both provide ld.so and that they can be removed in any order. The development of multiarch seems to be more or less stalled now, people being satisfied of being able to install packages from foreign architectures. To be able to progress further we need to solve the toolchain issue. They are multiple solutions from using foreign packages to build multilib toolchain, to stopping providing a multilib toolchain and using either cross compiler or allow both gcc:amd64 and gcc:i386 to be co-installable. In any case to support kernel and bootloader packages we need to create new architectures with a minimal set of packages (basically the toolchain). On the other hand if we just continue to wait, 32-bit architectures are going to die, and the kernel and bootloader issue will simply disappear ;-). I don't see anybody being against relaxing the requirement for /usr/local/libqual to exist, so we're presumably blocked on more seconds. Ok, great. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
On Thu, May 08, 2014 at 09:08:58AM +0200, Tollef Fog Heen wrote: ]] Aurelien Jarno How can we progress on this bug? We now have bugs #720777, #720778 and #720780 which ask for /usr/libqual to be created if /libqual exists. It's something that can be implemented, but before doing so, I would like to know if a decision has been taken wrt the policy. I think the whole libqual thing should be avoided and we should nack it for any new ports. Ideally, we should also try to get ourselves out of the hole we've dug ourselves into. I don't see anybody being against relaxing the requirement for /usr/local/libqual to exist, so we're presumably blocked on more seconds. Indeed, for policy to move forward we need input from knowledgeable developers. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
]] Aurelien Jarno On Thu, May 08, 2014 at 09:08:58AM +0200, Tollef Fog Heen wrote: ]] Aurelien Jarno How can we progress on this bug? We now have bugs #720777, #720778 and #720780 which ask for /usr/libqual to be created if /libqual exists. It's something that can be implemented, but before doing so, I would like to know if a decision has been taken wrt the policy. I think the whole libqual thing should be avoided and we should nack it for any new ports. Ideally, we should also try to get ourselves out of the hole we've dug ourselves into. Unfortunately given we still want to keep multilib compilers in the archive, we need to provide foreign binaries, and thus install them in libqual. The policy clearly states that a foreign binary should not be installed in the multiarch path, and that's really a good thing given how much pain multilib packages are already (especially when people start to install libc6-dev-amd64:i386 on an amd64 system or things like that). That is pretty orthogonal to whether we should require /usr/local/libqual to exist, which this bug is about, though. :-) I don't see anybody being against relaxing the requirement for /usr/local/libqual to exist, so we're presumably blocked on more seconds. Ok, great. A second would be great if you think we should relax the requirement. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
Hi, Tollef Fog Heen wrote: Suggested change: --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p /item + item +p + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists is removed. +/p + /item /enumlist Seconded. That makes two seconds by my count (me and ballombe). Remember that any DD including the one who proposed a change can second a proposal if they think it reflects consensus (or can solicit more input if they think it needs it). Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
Jonathan Nieder jrnie...@gmail.com writes: Tollef Fog Heen wrote: Suggested change: --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p /item + item +p + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists is removed. +/p + /item /enumlist Seconded. That makes two seconds by my count (me and ballombe). Remember that any DD including the one who proposed a change can second a proposal if they think it reflects consensus (or can solicit more input if they think it needs it). I second this as well, although I think it's unnecessary at this point. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
tags 613143 = pending quit Russ Allbery wrote: I second this as well, although I think it's unnecessary at this point. Thanks. Applied. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
On Thu, May 08, 2014 at 11:15:57AM -0700, Jonathan Nieder wrote: tags 613143 = pending quit Russ Allbery wrote: I second this as well, although I think it's unnecessary at this point. Thanks. Applied. Well, I was working on a patch that looks like: + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists (where + lt;qualgt; is either 32 or 64) is removed. i.e. try to explain what qual is. (Also I do not remember having seconded the patch, but it do not matter.) Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
Bill Allombert wrote: On Thu, May 08, 2014 at 11:15:57AM -0700, Jonathan Nieder wrote: Thanks. Applied. Well, I was working on a patch that looks like: + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists (where + lt;qualgt; is either 32 or 64) is removed. i.e. try to explain what qual is. FWIW I don't mind if you tweak the wording. Unfortunately it's not just qual = 32 or 64[1]. Luckily the only ones that would be relevant the way Debian uses qual are qual = 32 (mips, tilegx) qual = 64 (mips, powerpc, x86) qual = x32 (x86) from https://sourceware.org/glibc/wiki/ABIList. (Also I do not remember having seconded the patch, but it do not matter.) http://bugs.debian.org/613143#22 Thanks, Jonathan [1] The FHS just says There may be one or more variants. https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote: Bill Allombert wrote: On Thu, May 08, 2014 at 11:15:57AM -0700, Jonathan Nieder wrote: Thanks. Applied. Well, I was working on a patch that looks like: + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists (where + lt;qualgt; is either 32 or 64) is removed. i.e. try to explain what qual is. FWIW I don't mind if you tweak the wording. Unfortunately it's not just qual = 32 or 64[1]. Luckily the only ones that would be relevant the way Debian uses qual are qual = 32 (mips, tilegx) qual = 64 (mips, powerpc, x86) qual = x32 (x86) However the FHS version mandated by policy does not include libx32, so it could be argued that there is no need for a FHS exception for libx32. from https://sourceware.org/glibc/wiki/ABIList. Thanks for the link. (Also I do not remember having seconded the patch, but it do not matter.) http://bugs.debian.org/613143#22 Indeed! Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
Bill Allombert wrote: On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote: FWIW I don't mind if you tweak the wording. Unfortunately it's not just qual = 32 or 64[1]. Luckily the only ones that would be relevant the way Debian uses qual are qual = 32 (mips, tilegx) qual = 64 (mips, powerpc, x86) qual = x32 (x86) However the FHS version mandated by policy does not include libx32, so it could be argued that there is no need for a FHS exception for libx32. If I understand correctly then alas, no --- the FHS meaning of qual is open ended. When it describes lib32 and lib64 it says The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. This is a refinement of the general rules for /libqual and /usr/libqual. In other words, there are rules elsewhere in the document about how libqual works generally for lib32, lib64, libx32, libxyzzy, or whatever, and here are the more specific rules that govern lib, lib32, and lib64 on PPC64, s390x, sparc64, AMD64, and IA64. How about the following (text as before, except a parenthesized phrase added)? The requirement for /usr/local/libqual to exist if /libqual or /usr/libqual exists (where libqual is a variant of lib such as lib32 or lib64) is removed. such as should cover any future lib directories. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
]] Jonathan Nieder Seconded. That makes two seconds by my count (me and ballombe). Remember that any DD including the one who proposed a change can second a proposal if they think it reflects consensus (or can solicit more input if they think it needs it). I didn't realise you can second your own proposal, but I'm happy to second my proposal in that case, so seconded too. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
Tollef Fog Heen tfh...@err.no writes: ]] Jonathan Nieder Seconded. That makes two seconds by my count (me and ballombe). Remember that any DD including the one who proposed a change can second a proposal if they think it reflects consensus (or can solicit more input if they think it needs it). I didn't realise you can second your own proposal, but I'm happy to second my proposal in that case, so seconded too. Yeah, we require three seconds, but the proposer can second. I usually count the proposal as an implicit second if it's from a DD. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
block 720777 by 613143 block 720778 by 613143 block 720780 by 613143 thanks On Fri, Sep 23, 2011 at 10:18:05AM +0200, Bill Allombert wrote: On Thu, Sep 22, 2011 at 05:08:33PM -0500, Jonathan Nieder wrote: Tollef Fog Heen wrote: ]] Steve Langasek | How do we square that with the FHS, then? The FHS says: | | If directories /libqual or /usr/libqual exist, the equivalent | directories must also exist in /usr/local. | | That seems to require /usr/local/lib64 even if we *don't* include | /usr/lib64, right? Should we amend policy to take this exception to the | FHS? Please open a bug report on policy if you think we should. I think this is a bug in the FHS that we need to work around in Debian policy. libc6 2.13-17 removed the /lib64 and /usr/lib64 symlinks, so the problem described in bug#612000 no longer exists and there's no reason to want a /usr/local/lib64 symlink any more. We're left in the less worrisome situation Steve described, with the question of whether to create a (useless) /usr/local/lib64 directory. So now I can wholeheartedly endorse your proposed change. --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p /item + item +p + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists is removed. +/p + /item /enumlist /p Seconds? Seconded. The whole lib64 business was completly backward from the start. Ping! How can we progress on this bug? We now have bugs #720777, #720778 and #720780 which ask for /usr/libqual to be created if /libqual exists. It's something that can be implemented, but before doing so, I would like to know if a decision has been taken wrt the policy. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
On Thu, Sep 22, 2011 at 05:08:33PM -0500, Jonathan Nieder wrote: Tollef Fog Heen wrote: ]] Steve Langasek | How do we square that with the FHS, then? The FHS says: | | If directories /libqual or /usr/libqual exist, the equivalent | directories must also exist in /usr/local. | | That seems to require /usr/local/lib64 even if we *don't* include | /usr/lib64, right? Should we amend policy to take this exception to the | FHS? Please open a bug report on policy if you think we should. I think this is a bug in the FHS that we need to work around in Debian policy. libc6 2.13-17 removed the /lib64 and /usr/lib64 symlinks, so the problem described in bug#612000 no longer exists and there's no reason to want a /usr/local/lib64 symlink any more. We're left in the less worrisome situation Steve described, with the question of whether to create a (useless) /usr/local/lib64 directory. So now I can wholeheartedly endorse your proposed change. --- /proc/self/fd/132011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p /item + item +p + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists is removed. +/p + /item /enumlist /p Seconds? Seconded. The whole lib64 business was completly backward from the start. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. signature.asc Description: Digital signature
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
Tollef Fog Heen wrote: ]] Steve Langasek | How do we square that with the FHS, then? The FHS says: | | If directories /libqual or /usr/libqual exist, the equivalent | directories must also exist in /usr/local. | | That seems to require /usr/local/lib64 even if we *don't* include | /usr/lib64, right? Should we amend policy to take this exception to the | FHS? Please open a bug report on policy if you think we should. I think this is a bug in the FHS that we need to work around in Debian policy. libc6 2.13-17 removed the /lib64 and /usr/lib64 symlinks, so the problem described in bug#612000 no longer exists and there's no reason to want a /usr/local/lib64 symlink any more. We're left in the less worrisome situation Steve described, with the question of whether to create a (useless) /usr/local/lib64 directory. So now I can wholeheartedly endorse your proposed change. --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p /item + item +p + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists is removed. +/p + /item /enumlist /p Seconds? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
user debian-pol...@packages.debian.org severity 613143 wishlist usertags 613143 + normative discussion quit Hi Matthias, Aurelien, Santiago, Tollef Fog Heen wrote: Suggested change: --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p /item + item +p + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists is removed. +/p + /item See http://bugs.debian.org/612000 for context. In short, because (upstream, non-Debian) GCC searches all .../lib64 directories before .../lib directories, the search order is out of wack if a /usr/local/lib64 symlink does not exist: - /usr/local/lib64 (which does not exist) - /usr/lib (because /usr/lib64 is a symlink to it) - /lib (because /lib64 is a symlink to it) - /usr/local/lib - /usr/lib again ... That is, /usr/lib gets higher precedence than /usr/local/lib. The technical question before us is whether the libc6 package (or base-files or something) should provide a /usr/local/lib64 - lib symlink to get out of this mess. Any thoughts? Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
Package: debian-policy ]] Steve Langasek | On Fri, Feb 04, 2011 at 07:02:33PM +0100, Tollef Fog Heen wrote: | ]] Yaroslav Halchenko | | | please do not slap me too hard (only so that I feel your warm carrying | | touch): | | | is there a rationale for: on amd64 Debian systems having | | | /lib64 - /lib | | Yes, it's required by the ABI, unfortunately. | | | /usr/lib64 - /usr/lib | | Not really, apart from some broken software that will look for stuff | there and be confused if it doesn't exist. I think we should drop it. | | How do we square that with the FHS, then? The FHS says: | | If directories /libqual or /usr/libqual exist, the equivalent | directories must also exist in /usr/local. | | That seems to require /usr/local/lib64 even if we *don't* include | /usr/lib64, right? Should we amend policy to take this exception to the | FHS? Please open a bug report on policy if you think we should. I think this is a bug in the FHS that we need to work around in Debian policy. | /me goes back to making lib64 obsolete ;) Great! :-) Suggested change: --- /proc/self/fd/132011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p /item + item +p + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists is removed. +/p + /item /enumlist /p -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
