[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions

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:


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

> 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/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: