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

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/lib<qual> to be created if /lib<qual> 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 lib<qual> 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
lib<qual>. 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/lib<qual> to exist, so we're presumably blocked on more
> seconds.

Ok, great.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: