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 > 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.package > debian/package/DEBIAN/ >/lib/triplet and >/usr/lib/triplet, where >triplet is the value returned by > - dpkg-architecture -qDEB_HOST_GNU_TYPE for the > + dpkg-architecture -qDEB_HOST_MULTIARCH for the >architecture of the package. Packages may not >install files to any triplet path other >than the one matching the architecture of that package; >for instance, an Architecture: amd64 package >containing 32-bit x86 libraries may not install these > - libraries to /usr/lib/i486-linux-gnu. > + libraries to /usr/lib/i386-linux-gnu. > > 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 /usr/bin/mailx and implement at least the >POSIX-required interface. > > +9.1.1 > + Packages installing to architecture-specific subdirectories of > + /url/lib must use the value returned by > + dpkg-architecture -qDEB_HOST_MULTIARCH, not by > + dpkg-architecture -qDEB_HOST_GNU_TYPE; this is a path change > + on i386 architectures and a no-op for other architectures. > + > > > Version 3.9.1.0 > -- > 1.7.1 > Signed-off-by: Aurelien Jarno -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net 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 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.package debian/package/DEBIAN/ /lib/triplet and /usr/lib/triplet, where triplet is the value returned by - dpkg-architecture -qDEB_HOST_GNU_TYPE for the + dpkg-architecture -qDEB_HOST_MULTIARCH for the architecture of the package. Packages may not install files to any triplet path other than the one matching the architecture of that package; for instance, an Architecture: amd64 package containing 32-bit x86 libraries may not install these - libraries to /usr/lib/i486-linux-gnu. + libraries to /usr/lib/i386-linux-gnu. 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 /usr/bin/mailx and implement at least the POSIX-required interface. +9.1.1 + Packages installing to architecture-specific subdirectories of + /url/lib must use the value returned by + dpkg-architecture -qDEB_HOST_MULTIARCH, not by + dpkg-architecture -qDEB_HOST_GNU_TYPE; this is a path change + on i386 architectures and a no-op for other architectures. + Version 3.9.1.0 -- 1.7.1 signature.asc Description: Digital signature
Bug#591791: Bug#619093: splashy and systemd: error when trying to install together
Hi Steve! Am 21.03.2011 18:58, schrieb Steve Langasek: > On Mon, Mar 21, 2011 at 11:30:06AM +0100, Michael Biebl wrote: > > Right, in the policy proposal I am describing that each init script is > responsible for checking this. But the actual *implementation* of this > check can and should use a common shell library to do the heavy lifting. > Sorry, I didn't think that specifying that belonged in policy. Do you think > the use of a common shell library should be enforced in policy as part of > this? I do think it would make sense to agree on the name of such a shell library and at least mention and recommend it in the policy text. My concern is that if we don't encourage a common shell lib we get all sorts of inconsistencies and if we need to make adjustments later on (return codes etc) it's much easier to do it in one place. >> I'd much prefer if we could use the /lib/lsb/init-functions lib to do the >> same kind of redirecting for upstart. That is, all a package needs to do >> if it ships a native upstart job (or systemd service), is to include . >> /lib/lsb/init-functions in its sysv init script. lib/lsb/init-functions >> /would then do the correct thing, when it is run under >> systemd or upstart. > >> Steve, do you think this would be an approach that works for upstart (and >> Ubuntu)? > > I hadn't thought about having /lib/lsb/init-functions automatically do this > checking when sourced. I think on some level the idea offends me, the same > way having C libraries call setuid() or exit() offends me. :) Also, this > check is only needed for those packages that *ship* an upstart job, and > surely those packages know who they are and can handle the conversion easily > enough if we give them a function to call? True. The current version of upstart does not (yet) natively support SysV init scripts, and relies on /etc/init.d/rc to start those services. SysV services in upstart don't run under the supervision of upstart. In systemd the situation is a bit different, as SysV init scripts are basically just another configuration source and we also want to start SysV services under the supervision of systemd. I remember though Scott saying though that "native" SysV support was planned in upstart. So I'm just thinking ahead a bit. Using /lib/lsb/init-functions has the huge advantage that we already have a pretty good coverage of SysV init scripts using it (~70 %), which don't need to be changed to support this redirection scheme. For upstart with its current features, the shell lib would only redirect the call to initctl/upstart if if finds a upstart job with the same name as the SysV init script and would be a nop otherwise. Regarding the redirection scheme and your loathing of exit, how would you envision such an interface should look like? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#591791: Bug#619093: splashy and systemd: error when trying to install together
Hi Michael, On Mon, Mar 21, 2011 at 11:30:06AM +0100, Michael Biebl wrote: > So, in #591791 Steve proposed that packages should continue to ship sysv > init script, regardless if they have a native upstart job or not, and I > basically agree with that. > What I don't like about the proposal in #591791 is, that each sysv init > script should check itself, if it is run under upstart and exit. > This means we duplicate a lot of code and add upstart specific interna to > every init script shipping a native upstart job. Right, in the policy proposal I am describing that each init script is responsible for checking this. But the actual *implementation* of this check can and should use a common shell library to do the heavy lifting. Sorry, I didn't think that specifying that belonged in policy. Do you think the use of a common shell library should be enforced in policy as part of this? > I'd much prefer if we could use the /lib/lsb/init-functions lib to do the > same kind of redirecting for upstart. That is, all a package needs to do > if it ships a native upstart job (or systemd service), is to include . > /lib/lsb/init-functions in its sysv init script. lib/lsb/init-functions > /would then do the correct thing, when it is run under > systemd or upstart. > Steve, do you think this would be an approach that works for upstart (and > Ubuntu)? I hadn't thought about having /lib/lsb/init-functions automatically do this checking when sourced. I think on some level the idea offends me, the same way having C libraries call setuid() or exit() offends me. :) Also, this check is only needed for those packages that *ship* an upstart job, and surely those packages know who they are and can handle the conversion easily enough if we give them a function to call? -- 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#591791: Bug#619093: splashy and systemd: error when trying to install together
Am 21.03.2011 10:56, schrieb Michael Biebl: > Am 21.03.2011 08:07, schrieb Ralf Treinen: > >> Here is a list of files that are known to be shared by both packages >> (according to the Contents file for sid/amd64, which may be >> slightly out of sync): >> >> /etc/lsb-base-logging.sh > > The two packages don't share any kind of functionality in > /etc/lsb-base-logging.sh, so an alternatives approach or a simple Replaces > won't > work. > > splashy uses it to overwrite the logging calls, systemd to redirect the > complete > script to systemd, i.e. a call to > /etc/init.d/ > translates into > systemctl > > One might argue, that /etc/lsb-base-logging.sh is not the best place for that, > and I wouldn't disagree. Unfortunately there is afaik currently no better > place > to hook into the lsb init functions library. > > So I guess it's best if we move the systemd bits directly into lsb-base itself > and use a Conflicts against splashy until this is done. > > Chris, would you be ok with shipping the functionality of the systemd lsb init > hook [1] in lsb-base (/lib/lsb/init-functions) itself? > > > [1] > http://git.err.no/cgi-bin/gitweb.cgi?p=systemd;a=blob;f=debian/lsb-base-logging.sh;h=2998bdbb37df219e73e149b4b45ee400a9870a30;hb=refs/heads/debian I think this also affects #591791, so I CCed Steve and the debian-policy bug. Our original idea for upstart and sysv compatibility was, that packages shipping native upstart jobs would ship a symlink from /etc/init.d/foo → /lib/init/upstart-job, which translates it to initctl/upstart calls. This approach works, if you can rely on upstart being installed, which on Debian, especially on kfreebsd is not the case, so this idea never really took of. So, in #591791 Steve proposed that packages should continue to ship sysv init script, regardless if they have a native upstart job or not, and I basically agree with that. What I don't like about the proposal in #591791 is, that each sysv init script should check itself, if it is run under upstart and exit. This means we duplicate a lot of code and add upstart specific interna to every init script shipping a native upstart job. I'd much prefer if we could use the /lib/lsb/init-functions lib to do the same kind of redirecting for upstart. That is, all a package needs to do if it ships a native upstart job (or systemd service), is to include . /lib/lsb/init-functions in its sysv init script. /lib/lsb/init-functions would then do the correct thing, when it is run under systemd or upstart. Steve, do you think this would be an approach that works for upstart (and Ubuntu)? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
