/usr/lib64 or /usr/lib
Richard Ulrich
I want to package a library which hast the following lines in
CMakeLists.txt
IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(LIBDIR lib64)
ELSE (CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(LIBDIR lib)
ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
now, how do I have to handle this in debian/libxyz.install?
Rgds
Richard
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1307645250.5436.3.camel@quadulrich
Russ Allbery
> I want to package a library which hast the following lines in
> CMakeLists.txt
> IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
> SET(LIBDIR lib64)
> ELSE (CMAKE_SIZEOF_VOID_P EQUAL 8)
> SET(LIBDIR lib)
> ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
> now, how do I have to handle this in debian/libxyz.install?
On Debian, you should always install into lib and never use lib64.
(Eventually, you may want to use the multiarch directory, but it will
still not be lib64.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/877h8u2...@windlord.stanford.edu
David Bremner
>
> On Debian, you should always install into lib and never use lib64.
> (Eventually, you may want to use the multiarch directory, but it will
> still not be lib64.)
>
That was my first thought, but I couldn't find a straightforward
justification in
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
I wonder if a slight clarification is needed, or it's just me.
David
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
> On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery <r...@debian.org> wrote:
>> On Debian, you should always install into lib and never use lib64.
>> (Eventually, you may want to use the multiarch directory, but it will
>> still not be lib64.)
> That was my first thought, but I couldn't find a straightforward
> justification in
> http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
> I wonder if a slight clarification is needed, or it's just me.
9.1.1 point 2:
The requirement for amd64 to use /lib64 for 64 bit binaries is
removed.
Also note that /usr/lib64 is just a symlink to /usr/lib on Debian systems.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87wrguy...@windlord.stanford.edu
Thomas Preud'homme
> On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery <r...@debian.org> wrote:
> > On Debian, you should always install into lib and never use lib64.
> > (Eventually, you may want to use the multiarch directory, but it will
> > still not be lib64.)
>
> That was my first thought, but I couldn't find a straightforward
> justification in
>
> http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
>
> I wonder if a slight clarification is needed, or it's just me.
>
> David
True, it just say a library does not have to be installed in lib64. It does
not say it has to be installed in /lib IIRC.
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Bremner
>
> 9.1.1 point 2:
>
> The requirement for amd64 to use /lib64 for 64 bit binaries is
> removed.
Yeah, that is the point that confused me. For me, removing the
requirement is not the same as forbidding.
>
> Also note that /usr/lib64 is just a symlink to /usr/lib on Debian systems.
>
So that makes it a bit academic, at the moment.
cheers,
d
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Goswin von Brederlow
> On Thu, 09 Jun 2011 15:41:34 -0700, Russ Allbery <r...@debian.org> wrote:
>>
>> 9.1.1 point 2:
>>
>> The requirement for amd64 to use /lib64 for 64 bit binaries is
>> removed.
>
> Yeah, that is the point that confused me. For me, removing the
> requirement is not the same as forbidding.
Due to implementation issues (below) you MUST NOT ship any files in
/lib64 or /usr/lib64/ in the package.
>> Also note that /usr/lib64 is just a symlink to /usr/lib on Debian systems.
>>
>
> So that makes it a bit academic, at the moment.
>
> cheers,
>
> d
Except for how dpkg behaves. If your package has a file in /usr/lib64/
and gets installed then dpkg records that that directory belongs to your
package. Then the next time libc6 gets updated dpkg will try to unpack
the /usr/lib64 symlink and fail because you can not replace a directory
of another package with a symlink. You have made it impossible to update
libc6.
MfG
Goswin
PS: You can (and should if you have plugins) configure/build your
package to use /lib64 and /usr/lib64 as long as you ship it as /lib and
/usr/lib in the deb.
PPS: Using multiarch dirs would be even better for plugins.
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87y618v...@frosties.localnet
Sven Joachim
> Except for how dpkg behaves. If your package has a file in /usr/lib64/
> and gets installed then dpkg records that that directory belongs to your
> package. Then the next time libc6 gets updated dpkg will try to unpack
> the /usr/lib64 symlink and fail because you can not replace a directory
> of another package with a symlink.
Er no, this is not how dpkg behaves. It never converts symlinks to
directories or vice versa, so the actual outcome is¹ that your file gets
actually installed into /usr/lib through the symlink. This means that
if another package starts shipping a file with the same name in
/usr/lib, dpkg will not notice the file conflict which is bad.
It's much worse if you ship files in /lib64, because if your package is
installed into a chroot and unpacked by the host dpkg with the --root=…
option, the files end up in the host system².
Sven
¹ Unless your package is unpacked before libc6 while bootstrapping a
system, but that's highly unlikely.
² http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514702
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
> Er no, this is not how dpkg behaves. It never converts symlinks to
> directories or vice versa, so the actual outcome is¹ that your file gets
> actually installed into /usr/lib through the symlink. This means that
> if another package starts shipping a file with the same name in
> /usr/lib, dpkg will not notice the file conflict which is bad.
> It's much worse if you ship files in /lib64, because if your package is
> installed into a chroot and unpacked by the host dpkg with the --root=…
> option, the files end up in the host system².
So we should absolutely forbid this in Policy instead of just removing the
requirement. I'll open a bug against debian-policy for this.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87y618k...@windlord.stanford.edu
Goswin von Brederlow
> On 2011-06-11 09:22 +0200, Goswin von Brederlow wrote:
>
>> Except for how dpkg behaves. If your package has a file in /usr/lib64/
>> and gets installed then dpkg records that that directory belongs to your
>> package. Then the next time libc6 gets updated dpkg will try to unpack
>> the /usr/lib64 symlink and fail because you can not replace a directory
>> of another package with a symlink.
>
> Er no, this is not how dpkg behaves. It never converts symlinks to
> directories or vice versa, so the actual outcome is¹ that your file gets
> actually installed into /usr/lib through the symlink. This means that
> if another package starts shipping a file with the same name in
> /usr/lib, dpkg will not notice the file conflict which is bad.
Please read again. Nothing gets converted. dpkg just fails with a file
overwrite error because /usr/lib64 belongs to another package and is not
a directory in libc6. And only directories are allowed to be in multiple
packages.
> It's much worse if you ship files in /lib64, because if your package is
> installed into a chroot and unpacked by the host dpkg with the --root=…
> option, the files end up in the host system².
>
> Sven
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87mxhmm...@frosties.localnet
Sven Joachim
> Sven Joachim <sven...@gmx.de> writes:
>
>> On 2011-06-11 09:22 +0200, Goswin von Brederlow wrote:
>>
>>> Except for how dpkg behaves. If your package has a file in /usr/lib64/
>>> and gets installed then dpkg records that that directory belongs to your
>>> package. Then the next time libc6 gets updated dpkg will try to unpack
>>> the /usr/lib64 symlink and fail because you can not replace a directory
>>> of another package with a symlink.
>>
>> Er no, this is not how dpkg behaves. It never converts symlinks to
>> directories or vice versa, so the actual outcome is¹ that your file gets
>> actually installed into /usr/lib through the symlink. This means that
>> if another package starts shipping a file with the same name in
>> /usr/lib, dpkg will not notice the file conflict which is bad.
>
> Please read again. Nothing gets converted. dpkg just fails with a file
> overwrite error because /usr/lib64 belongs to another package and is not
> a directory in libc6. And only directories are allowed to be in multiple
> packages.
You seem to have a very old version of dpkg, in this situation there has
been no file overwrite error for a few years:
,----
| dpkg (1.14.6) unstable; urgency=low
| [...]
| * Do not consider it a file conflict if the package contains a symlink
| to a directory where the existing symlink on-disk points to the
| same place. Closes: #377682
| Thanks to Ian Jackson.
| [...]
| -- Guillem Jover <gui...@debian.org> Wed, 05 Sep 2007 07:36:02 +0300
`----
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Goswin von Brederlow
> Sven Joachim <sven...@gmx.de> writes:
>
>> Er no, this is not how dpkg behaves. It never converts symlinks to
>> directories or vice versa, so the actual outcome is¹ that your file gets
>> actually installed into /usr/lib through the symlink. This means that
>> if another package starts shipping a file with the same name in
>> /usr/lib, dpkg will not notice the file conflict which is bad.
>
>> It's much worse if you ship files in /lib64, because if your package is
>> installed into a chroot and unpacked by the host dpkg with the --root=…
>> option, the files end up in the host system².
>
> So we should absolutely forbid this in Policy instead of just removing the
> requirement. I'll open a bug against debian-policy for this.
Forbid what? Absolut symlinks? Or packages shipping files in directories
that are symlinks in other packages?
The later is already a RC bug.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87zkljo...@frosties.localnet
Goswin von Brederlow
It's been a while since I've seen the problem. Not sure if it has been 4
years or not. We had this issue a lot with KDE packages early in the
amd64 port.
The patch from #377682 might fix this issue for upgrades. But that
leaves the problem of new installs. If the package with the
/usr/lib64/foo file is unpacked first then /usr/lib64 is not a symlink
and then libc6 still has a file overwrite problem.
So overall this changes nothing.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87k4cno...@frosties.localnet