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

Bug#367962: marked as done (Please don't ship a /lib64 symlink in the package on amd64)



Your message dated Tue, 07 Feb 2012 22:49:04 +0100
with message-id <87obtafh67.fsf@turtle.gmx.de>
and subject line /lib64 symlink removed in libc6 2.13-17
has caused the Debian Bug report #367962,
regarding Please don't ship a /lib64 symlink in the package on amd64
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
367962: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367962
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.3.6-7
Severity: normal

Hi,

Currently the libc6 package on amd64 ships a symlink from /lib64 to
/lib (and /usr/lib64). While the symlink is needed for things to work
shipping it in the data.tar.gz makes it impossible for any package to
put files into /lib64 or /usr/lib64 (as specified by FHS):

If any package does so the next time libc6 gets updated you get an
error similar to:

dpkg: error processing foo1-1.0.deb (--install):
 trying to overwrite `/foo', which is also in package foo2


Instead of shipping the symlinks I suggest creating them in the
preinst (if they don't exist) and shipping at least one file
(/lib64/ld-2.3.2.so comes to mind) in /lib64 and /usr/lib64 to prevent
dpkg from removing the links on updates.


Why would we want this?

With that change packages can be patched (or un-patched) to use the
FHS compliant lib64 dirs. Libraries and plugins are then in a
different directory than on i386 alowing for automatic conversion of
amd64 packages to an i386 based bi-arch system.

Also if enough packages get changed to /lib64 the symlinks could be
droped and bugs filed against the remaining packages. Updating to a
non symlinks way might be tricky but at least new installs would get
the right dirs.

MfG
	Goswin

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.16-rc4-xen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-7    The Berkeley database routines [gl

-- no debconf information


--- End Message ---
--- Begin Message ---
Package: eglibc
Version: 2.13-17

Starting with version 2.13-17, /lib64 is now a directory on amd64,
rather than a symlink.  See #632682.


--- End Message ---

Reply to: