Hi Jonathan, On Tue, Mar 29, 2011 at 02:05:45PM -0500, Jonathan Nieder wrote: > > 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. :) Guillem raised this issue as well, but we couldn't come to an agreement on a name that was both clear and not irksomely verbose. I think multiarch will soon be pervasive enough that people will become accustomed to it and I'm not too concerned about finding the perfect name. > * 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)? The rollout plan looks like this: 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. I wasn't planning to change policy for this. It's transitional, so we would be adding it to policy for just one release cycle before wanting to drop it again; I think it's covered by the general rule that "policy doesn't need to exhaustively document everything a package can do wrong that would make it buggy"; and although I'm preparing patches with caution so that every package that switches to multiarch has the necessary Pre-Depends: multiarch-support, the downside of getting this wrong is pretty small for packages outside the base system and package manager (upgrade libc6 and everything's fixed). If you think this is important to document in policy anyway, I can prepare a patch. > Is it intended to make packages using the old variable instantly RC-buggy > (I think "yes", but it seems best to ask)? Yes. There are only three packages affected (libhwloc, liblouis, liblouisxml) affected by the library path change; all of these should be switched over to the final path before wheezy releases, so eglibc doesn't have to carry transitional support for /usr/lib/i486-linux-gnu for more than one release cycle. -- 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 Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
