Sven Joachim writes:
> On 2011-06-13 12:11 +0200, Goswin von Brederlow wrote:
>
>> Sven Joachim 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 tha
Russ Allbery writes:
> Sven Joachim 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
On 2011-06-13 12:11 +0200, Goswin von Brederlow wrote:
> Sven Joachim 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
>>>
Sven Joachim 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
Sven Joachim 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
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 symli
David Bremner writes:
> On Thu, 09 Jun 2011 15:41:34 -0700, Russ Allbery 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 forb
On Thu, 09 Jun 2011 15:41:34 -0700, Russ Allbery 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.
>
> Also note that /usr/li
Le vendredi 10 juin 2011 00:38:12, David Bremner a écrit :
> On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery 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 w
David Bremner writes:
> On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery 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
On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery 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
justif
Richard Ulrich writes:
> 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 i
Hi Mentors,
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?
Rg
13 matches
Mail list logo