please do not slap me too hard (only so that I feel your warm carrying
touch):

is there a rationale for: on amd64 Debian systems having

/lib64 -> /lib
/usr/lib64 -> /usr/lib

but no similar one for /usr/local/lib64, so that directory
/usr/local/lib64 gets created if anyone (with enough rights) does 'make
install' pointing there; and we do not include /usr/local/lib64 into ldconfig
path (by default), so those libraries 'get lost'

aren't we diverging from FHS:

If directories /lib<qual> or /usr/lib<qual> exist, the equivalent directories must also exist in /usr/local.

?

thanks for the input
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110204060813.GA16363@onerussian.com">http://lists.debian.org/20110204060813.GA16363@onerussian.com

Yaroslav Halchenko <debian@onerussian.com> writes:

> please do not slap me too hard (only so that I feel your warm carrying
> touch):
>
> is there a rationale for: on amd64 Debian systems having
>
> /lib64 -> /lib
> /usr/lib64 -> /usr/lib
>
> but no similar one for /usr/local/lib64, so that directory
> /usr/local/lib64 gets created if anyone (with enough rights) does 'make
> install' pointing there; and we do not include /usr/local/lib64 into ldconfig
> path (by default), so those libraries 'get lost'
>
> aren't we diverging from FHS:
>
> If directories /lib<qual> or /usr/lib<qual> exist, the equivalent directories must also exist in /usr/local.
>
> ?

No reason and yes.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipx0tacz.fsf@frosties.localnet">http://lists.debian.org/87ipx0tacz.fsf@frosties.localnet

I guess then it might be sensible to get /usr/local/lib64 ->
/usr/local/lib .

ok -- lets see what libc6 maintainers think about that
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612000

On Fri, 04 Feb 2011, Goswin von Brederlow wrote:

> > aren't we diverging from FHS:

> > If directories /lib<qual> or /usr/lib<qual> exist, the equivalent directories must also exist in /usr/local.

> > ?
> No reason and yes.

--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110204151548.GZ8747@onerussian.com">http://lists.debian.org/20110204151548.GZ8747@onerussian.com

]] Yaroslav Halchenko

| please do not slap me too hard (only so that I feel your warm carrying
| touch):
|
| is there a rationale for: on amd64 Debian systems having
|
| /lib64 -> /lib

Yes, it's required by the ABI, unfortunately.

| /usr/lib64 -> /usr/lib

Not really, apart from some broken software that will look for stuff
there and be confused if it doesn't exist. I think we should drop it.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87oc6rk79i.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87oc6rk79i.fsf@qurzaw.varnish-software.com

On 2011-02-04 19:02:33 +0100, Tollef Fog Heen wrote:
> ]] Yaroslav Halchenko
> | /usr/lib64 -> /usr/lib
>
> Not really, apart from some broken software that will look for stuff
> there and be confused if it doesn't exist. I think we should drop it.

Thanks would be a good thing. Otherwise users should either avoid
upstream GCC's or add similar symbolic links for every directory
(e.g. $HOME/lib64 -> $HOME/lib if the user installs software in
his home directory). FYI, here's the problem I had under Debian
because of this symbolic link:

http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html
(and followups)

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110211125238.GG15920@prunille.vinc17.org">http://lists.debian.org/20110211125238.GG15920@prunille.vinc17.org

On Fri, Feb 04, 2011 at 07:02:33PM +0100, Tollef Fog Heen wrote:
> ]] Yaroslav Halchenko

> | please do not slap me too hard (only so that I feel your warm carrying
> | touch):

> | is there a rationale for: on amd64 Debian systems having

> | /lib64 -> /lib

> Yes, it's required by the ABI, unfortunately.

> | /usr/lib64 -> /usr/lib

> Not really, apart from some broken software that will look for stuff
> there and be confused if it doesn't exist. I think we should drop it.

How do we square that with the FHS, then? The FHS says:

If directories /lib<qual> or /usr/lib<qual> exist, the equivalent
directories must also exist in /usr/local.

That seems to require /usr/local/lib64 even if we *don't* include
/usr/lib64, right? Should we amend policy to take this exception to the
FHS? Please open a bug report on policy if you think we should.

/me goes back to making lib64 obsolete
--
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

]] Steve Langasek

| That seems to require /usr/local/lib64 even if we *don't* include
| /usr/lib64, right? Should we amend policy to take this exception to the
| FHS? Please open a bug report on policy if you think we should.

I've just opened such a bug.

| /me goes back to making lib64 obsolete

Yay! :-)

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87lj1ktkpm.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87lj1ktkpm.fsf@qurzaw.varnish-software.com

On 2011-02-12 17:44:27 -0800, Steve Langasek wrote:
> How do we square that with the FHS, then? The FHS says:
>
> If directories /lib<qual> or /usr/lib<qual> exist, the equivalent
> directories must also exist in /usr/local.
>
> That seems to require /usr/local/lib64 even if we *don't* include
> /usr/lib64, right? Should we amend policy to take this exception to the
> FHS? Please open a bug report on policy if you think we should.

What's important is consistency. The tools under Debian don't expect
libraries to be in **/lib64, but in **/lib.

> /me goes back to making lib64 obsolete

Yes!

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110215233512.GK15920@prunille.vinc17.org">http://lists.debian.org/20110215233512.GK15920@prunille.vinc17.org

user debian-policy@packages.debian.org
severity 613143 wishlist
usertags 613143 + normative discussion
quit

Hi Matthias, Aurelien, Santiago,

Tollef Fog Heen wrote:

> Suggested change:
>
> --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100
> +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100
> @@ -5993,6 +5993,13 @@
> to get access to kernel information.</footnote>
> </p>
> </item>
> + <item>
> + <p>
> + The requirement for <file>/usr/local/lib&lt;qual&gt;</file>
> + to exist if <file>/lib&lt;qual&gt</file> or
> + <file>/usr/lib&lt;qual&gt</file> exists is removed.
> + </p>
> + </item>

See http://bugs.debian.org/612000 for context. In short,
because (upstream, non-Debian) GCC searches all .../lib64 directories
before .../lib directories, the search order is out of wack if a
/usr/local/lib64 symlink does not exist:

- /usr/local/lib64 (which does not exist)
- /usr/lib (because /usr/lib64 is a symlink to it)
- /lib (because /lib64 is a symlink to it)
- /usr/local/lib
- /usr/lib again
...

That is, /usr/lib gets higher precedence than /usr/local/lib.

The technical question before us is whether the libc6 package (or
base-files or something) should provide a /usr/local/lib64 -> lib
symlink to get out of this mess.

Any thoughts?
Jonathan


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110302013154.GA12160@elie">http://lists.debian.org/20110302013154.GA12160@elie