Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
Steve Langasek vor...@debian.org writes: Attached is a patch to update policy's FHS exception to reflect the current consensus among the gcc, eglibc, and dpkg maintainers around the paths to use for implementation and the interface packages should use to query these paths. Thanks, applied. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4fapw9r@windlord.stanford.edu
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
user debian-pol...@packages.debian.org tags 619186 = usertags 619186 = normative seconded quit Steve Langasek wrote: On Tue, Mar 29, 2011 at 05:21:59PM -0500, Jonathan Nieder wrote: Steve Langasek wrote: If you think this is important to document in policy anyway, I can prepare a patch. Yes, please. I agree with you that the normative component is already taken care of by don't be buggy, so if can be written in the informative style, that would be great. Do you mind if I split the informative text off onto a separate bug report? No, I don't mind (though I hope it doesn't fall off the radar). Cheers, Jonathan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110402060819.GA8016@elie
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
On Tue, Mar 29, 2011 at 05:21:59PM -0500, Jonathan Nieder wrote: Steve Langasek wrote: http://wiki.debian.org/Multiarch/Bootstrapping The current ld.so doesn't yet know about the final path (on i386), so libraries can't switch to using it or they'll fail to be found by the runtime linker. Since we don't want to wait until the next release cycle before being able to proceed to step 5, this does mean that a transitional dependency is needed to ensure a multiarch-compatible ld.so is unpacked before libraries unpack to /lib/i386-linux-gnu. [...] If you think this is important to document in policy anyway, I can prepare a patch. Yes, please. I agree with you that the normative component is already taken care of by don't be buggy, so if can be written in the informative style, that would be great. Do you mind if I split the informative text off onto a separate bug report? Thanks, -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
user debian-pol...@packages.debian.org usertags 619186 = seconded thanks If I understand the current policy process, this has met the necessary number of sign-offs (proposer + 2 seconds == 3 sign-offs), so marking as 'seconded'. Is there a policy czar available to confirm this and maybe to nudge this bug along its way? :) Note that the dpkg implementation of what's described here is imminent, so it would be good to have confirmation that it's ok on the policy side for us to use this. Thanks, -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
Steve Langasek wrote: If I understand the current policy process, this has met the necessary number of sign-offs (proposer + 2 seconds == 3 sign-offs), so marking as 'seconded'. Yes, and the change sounds good to me. Thanks. Is there a policy czar available to confirm this and maybe to nudge this bug along its way? :) Note that the dpkg implementation of what's described here is imminent, so it would be good to have confirmation that it's ok on the policy side for us to use this. As a curious bystander: * I understand that there is history behind it, so I am not advocating changing this, but the name DEB_HOST_MULTIARCH is not so self-explanatory. I suppose what it actually means is something like DEB_HOST_PATH_COMPONENT. Hopefully as the cross-distro simplified GNU triplets get used for other things, the DEB_HOST_MULTIARCH name will start to seem more natural. :) * Is it safe to start using the new variable right away, without changing declared dependencies (I would hope yes if policy advocates it without caveats)? Is it intended to make packages using the old variable instantly RC-buggy (I think yes, but it seems best to ask)? -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110329190545.GA32649@elie
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
Steve Langasek wrote: http://wiki.debian.org/Multiarch/Bootstrapping The current ld.so doesn't yet know about the final path (on i386), so libraries can't switch to using it or they'll fail to be found by the runtime linker. Since we don't want to wait until the next release cycle before being able to proceed to step 5, this does mean that a transitional dependency is needed to ensure a multiarch-compatible ld.so is unpacked before libraries unpack to /lib/i386-linux-gnu. [...] If you think this is important to document in policy anyway, I can prepare a patch. Yes, please. I agree with you that the normative component is already taken care of by don't be buggy, so if can be written in the informative style, that would be great. Also I suppose some discussion on debian-devel has already taken place to make this pre-dependency possible without worrying about policy §3.5? If not, I'd be interested in either an explicit exception or the perfunctory discussion on -devel, whichever is easier. Cheers, Jonathan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110329222159.GA14578@elie
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
On Mon, 21 Mar 2011, Steve Langasek wrote: Attached is a patch to update policy's FHS exception to reflect the current consensus among the gcc, eglibc, and dpkg maintainers around the paths to use for implementation and the interface packages should use to query these paths. [...] From 1f0f1281c53701e2fe549ed9f80a265ebcd9282a Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Mon, 21 Mar 2011 02:17:14 -0700 Subject: [PATCH] Fix multiarch FHS exception for i386 in light of recent discussions The current value of DEB_HOST_GNU_TYPE on i386 is unsuitable for cross-distro standardization, because it varies according to the default CPU target of the toolchain. Discussion with the toolchain and dpkg maintainers yielded an alternative solution, a new dpkg-architecture variable DEB_HOST_MULTIARCH which is committed to dpkg upstream in commit af3153d09aa3ed5597d6d415e5ab7cc3ba972e7c and will be included in the upload of dpkg 1.16.0. Update Policy to document this new requirement for multiarch. Seconded. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) signature.asc Description: Digital signature
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
Package: debian-policy Version: 3.9.1.0 Severity: normal Tags: patch User: debian-pol...@packages.debian.org Usertags: normative Hi guys, Attached is a patch to update policy's FHS exception to reflect the current consensus among the gcc, eglibc, and dpkg maintainers around the paths to use for implementation and the interface packages should use to query these paths. Cc:ing the respective maintainer mailing lists for sign-off. Thanks, -- 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/ slanga...@ubuntu.com vor...@debian.org From 1f0f1281c53701e2fe549ed9f80a265ebcd9282a Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Mon, 21 Mar 2011 02:17:14 -0700 Subject: [PATCH] Fix multiarch FHS exception for i386 in light of recent discussions The current value of DEB_HOST_GNU_TYPE on i386 is unsuitable for cross-distro standardization, because it varies according to the default CPU target of the toolchain. Discussion with the toolchain and dpkg maintainers yielded an alternative solution, a new dpkg-architecture variable DEB_HOST_MULTIARCH which is committed to dpkg upstream in commit af3153d09aa3ed5597d6d415e5ab7cc3ba972e7c and will be included in the upload of dpkg 1.16.0. Update Policy to document this new requirement for multiarch. --- policy.sgml |4 ++-- upgrading-checklist.sgml |7 +++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/policy.sgml b/policy.sgml index 6e04c81..c708a18 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6027,13 +6027,13 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ file/lib/vartriplet/var/file and file/usr/lib/vartriplet/var/file, where ttvartriplet/var/tt is the value returned by - ttdpkg-architecture -qDEB_HOST_GNU_TYPE/tt for the + ttdpkg-architecture -qDEB_HOST_MULTIARCH/tt for the architecture of the package. Packages may emnot/em install files to any vartriplet/var path other than the one matching the architecture of that package; for instance, an ttArchitecture: amd64/tt package containing 32-bit x86 libraries may not install these - libraries to file/usr/lib/i486-linux-gnu/file. + libraries to file/usr/lib/i386-linux-gnu/file. footnote This is necessary in order to reserve the directories for use in cross-installation of library packages from other diff --git a/upgrading-checklist.sgml b/upgrading-checklist.sgml index e696077..2138b5c 100644 --- a/upgrading-checklist.sgml +++ b/upgrading-checklist.sgml @@ -58,6 +58,13 @@ Unreleased. that install prgn/usr/bin/mailx/prgn and implement at least the POSIX-required interface. /item +tag9.1.1/tag + itemPackages installing to architecture-specific subdirectories of + file/url/lib/file must use the value returned by + prgndpkg-architecture -qDEB_HOST_MULTIARCH/prgn, not by + prgndpkg-architecture -qDEB_HOST_GNU_TYPE/prgn; this is a path change + on i386 architectures and a no-op for other architectures. + /item /taglist/p sect Version 3.9.1.0 -- 1.7.1 signature.asc Description: Digital signature
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
On Mon, Mar 21, 2011 at 02:34:36PM -0700, Steve Langasek wrote: Package: debian-policy Version: 3.9.1.0 Severity: normal Tags: patch User: debian-pol...@packages.debian.org Usertags: normative Hi guys, Attached is a patch to update policy's FHS exception to reflect the current consensus among the gcc, eglibc, and dpkg maintainers around the paths to use for implementation and the interface packages should use to query these paths. Cc:ing the respective maintainer mailing lists for sign-off. Thanks, -- 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/ slanga...@ubuntu.com vor...@debian.org From 1f0f1281c53701e2fe549ed9f80a265ebcd9282a Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Mon, 21 Mar 2011 02:17:14 -0700 Subject: [PATCH] Fix multiarch FHS exception for i386 in light of recent discussions The current value of DEB_HOST_GNU_TYPE on i386 is unsuitable for cross-distro standardization, because it varies according to the default CPU target of the toolchain. Discussion with the toolchain and dpkg maintainers yielded an alternative solution, a new dpkg-architecture variable DEB_HOST_MULTIARCH which is committed to dpkg upstream in commit af3153d09aa3ed5597d6d415e5ab7cc3ba972e7c and will be included in the upload of dpkg 1.16.0. Update Policy to document this new requirement for multiarch. --- policy.sgml |4 ++-- upgrading-checklist.sgml |7 +++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/policy.sgml b/policy.sgml index 6e04c81..c708a18 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6027,13 +6027,13 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ file/lib/vartriplet/var/file and file/usr/lib/vartriplet/var/file, where ttvartriplet/var/tt is the value returned by - ttdpkg-architecture -qDEB_HOST_GNU_TYPE/tt for the + ttdpkg-architecture -qDEB_HOST_MULTIARCH/tt for the architecture of the package. Packages may emnot/em install files to any vartriplet/var path other than the one matching the architecture of that package; for instance, an ttArchitecture: amd64/tt package containing 32-bit x86 libraries may not install these - libraries to file/usr/lib/i486-linux-gnu/file. + libraries to file/usr/lib/i386-linux-gnu/file. footnote This is necessary in order to reserve the directories for use in cross-installation of library packages from other diff --git a/upgrading-checklist.sgml b/upgrading-checklist.sgml index e696077..2138b5c 100644 --- a/upgrading-checklist.sgml +++ b/upgrading-checklist.sgml @@ -58,6 +58,13 @@ Unreleased. that install prgn/usr/bin/mailx/prgn and implement at least the POSIX-required interface. /item +tag9.1.1/tag + itemPackages installing to architecture-specific subdirectories of + file/url/lib/file must use the value returned by + prgndpkg-architecture -qDEB_HOST_MULTIARCH/prgn, not by + prgndpkg-architecture -qDEB_HOST_GNU_TYPE/prgn; this is a path change + on i386 architectures and a no-op for other architectures. + /item /taglist/p sect Version 3.9.1.0 -- 1.7.1 Signed-off-by: Aurelien Jarno aure...@debian.org -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
