* Bernhard R. Link brl...@debian.org schrieb:
They do not only include the library in question, but they include many
other libraries. As paths supplied by the user are searched in before
anything in the system path, this changes the order the system paths are
searched in.
This can both hide
* Roger Leigh rle...@codelibre.net schrieb:
Well, they end up on / to give you /games, /include, /local, /share
and /src. Because /usr is a symlink to /, these are still accessible
as /usr/games, /usr/include etc. for full backward compatibility.
If it's just about getting rid of two
On 2011-01-05 08:46 +0100, Mike Hommey wrote:
On Wed, Jan 05, 2011 at 03:29:08AM +0100, Michael Biebl wrote:
Nice write-up, you raise many good points I agree with.
Just a small remark:
On 05.01.2011 01:25, Roger Leigh wrote:
2) /usr is mounted read-only for security and safety
On Wed, Jan 5, 2011 at 1:25 AM, Roger Leigh rle...@codelibre.net wrote:
Well, that's the issue at hand. The reason I mentioned this is
because I believe that the / and /usr separation is a case where we
should stop to consider the bigger picture rather than just the
immediate problem. Solving
Mike Hommey m...@glandium.org (05/01/2011):
It requires a recent kernel, though. IIRC, Lenny kernels don't
support readonly bind mounts.
readonly bind mount support appeared in 2.6.26, at least according to
the first point in [1].
1. http://kernelnewbies.org/Linux_2_6_26
KiBi.
On Wed, Jan 05, 2011 at 12:44:34PM +0100, Olaf van der Spek wrote:
On Wed, Jan 5, 2011 at 1:25 AM, Roger Leigh rle...@codelibre.net wrote:
Well, that's the issue at hand. The reason I mentioned this is
because I believe that the / and /usr separation is a case where we
should stop to
On Wed, Jan 5, 2011 at 1:18 PM, Roger Leigh rle...@codelibre.net wrote:
You're right. Is there a project goal for this yet?
No, that's one of the reasons I've brought it up.
Practically speaking, this can be done fairly easily. There's no
need to ban having a separate /usr at all. Having
On Wed, Jan 05, 2011 at 01:57:31PM +0100, Olaf van der Spek wrote:
On Wed, Jan 5, 2011 at 1:18 PM, Roger Leigh rle...@codelibre.net wrote:
You're right. Is there a project goal for this yet?
No, that's one of the reasons I've brought it up.
Practically speaking, this can be done fairly
On Wed, Jan 5, 2011 at 3:15 PM, Roger Leigh rle...@codelibre.net wrote:
I doubt it. The symlink doesn't work right now due to the same file
being present on both paths, causing one to be overwritten. Once that
issue is solved, it should not impact upon keeping /usr separate. As
long as a
On Wed, 5 Jan 2011 16:42:29 +0100
Olaf van der Spek olafvds...@gmail.com wrote:
On Wed, Jan 5, 2011 at 3:15 PM, Roger Leigh rle...@codelibre.net wrote:
I doubt it. The symlink doesn't work right now due to the same file
being present on both paths, causing one to be overwritten. Once that
]] Roger Leigh
| On Mon, Jan 03, 2011 at 10:33:21PM +0100, Olaf van der Spek wrote:
| I've never used pkgconfig. But if it doesn't support it, it too should be
fixed.
First, it's pkg-config, and secondly, no, it shouldn't. pkg-config
doesn't try to be everything to everybod and I haven't
On Tue, Jan 4, 2011 at 9:38 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Roger Leigh
| On Mon, Jan 03, 2011 at 10:33:21PM +0100, Olaf van der Spek wrote:
| I've never used pkgconfig. But if it doesn't support it, it too should be
fixed.
First, it's pkg-config, and secondly, no, it
* Olaf van der Spek olafvds...@gmail.com [110104 11:20]:
On Tue, Jan 4, 2011 at 9:38 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Roger Leigh
| On Mon, Jan 03, 2011 at 10:33:21PM +0100, Olaf van der Spek wrote:
| I've never used pkgconfig. But if it doesn't support it, it too should
]] Olaf van der Spek
| On Tue, Jan 4, 2011 at 9:38 AM, Tollef Fog Heen tfh...@err.no wrote:
| ]] Roger Leigh
|
| | On Mon, Jan 03, 2011 at 10:33:21PM +0100, Olaf van der Spek wrote:
|
| | I've never used pkgconfig. But if it doesn't support it, it too should
be fixed.
|
| First, it's
On Tue, Jan 4, 2011 at 1:42 PM, Tollef Fog Heen tfh...@err.no wrote:
| Eh, wouldn't this case be a valid use case?
No, there's no reason for the .so to live in /lib rather than /usr/lib.
What about .so files needed before /usr is mounted?
Olaf
--
To UNSUBSCRIBE, email to
]] Olaf van der Spek
| On Tue, Jan 4, 2011 at 1:42 PM, Tollef Fog Heen tfh...@err.no wrote:
| | Eh, wouldn't this case be a valid use case?
|
| No, there's no reason for the .so to live in /lib rather than /usr/lib.
|
| What about .so files needed before /usr is mounted?
Do you have a
On Tue, Jan 4, 2011 at 2:40 PM, Tollef Fog Heen tfh...@err.no wrote:
| What about .so files needed before /usr is mounted?
Do you have a non-contrived example of a .so file which is needed before
/usr is mounted and where there's a need for a static library?
Why the second part of that
* Andreas Metzler ametz...@downhill.at.eu.org schrieb:
in a nutshell: I doubt anybody who has the knowledge to fix it cares,
and there is more to it than a
--with-stuff-usually-in-libdir-but-we-want-it-below-urs=/usr/lib.
Installing it there is simple, making use of the installed files is
* Bernhard R. Link brl...@debian.org schrieb:
We are talking about things stored in /lib or /usr/lib here, i.e. something
stored in a system path.
Sadly pkg-config does not support this, so there will be some -L
recorded with some path, which one has to hope will later be removed
by
On Tue, Jan 04, 2011 at 09:38:19AM +0100, Tollef Fog Heen wrote:
| An alternative strategy to consider for the future: drop /usr entirely
| and place all libraries in /lib [as done on GNU/Hurd]. On current
| systems using initramfs the need for a separate / and /usr is gone.
| IMHO, there are
On 2011-01-04 16:33 +0100, Steve Langasek wrote:
On Tue, Jan 04, 2011 at 09:38:19AM +0100, Tollef Fog Heen wrote:
| An alternative strategy to consider for the future: drop /usr entirely
| and place all libraries in /lib [as done on GNU/Hurd]. On current
| systems using initramfs the need
Steve Langasek, le Tue 04 Jan 2011 07:33:04 -0800, a écrit :
In what way is it not already possible to symlink /usr to /?
We've abandoned that for the GNU/Hurd port notably because as of now it
messes up library resolution, e.g. a library is found in /lib/libfoo
while it's actually packaged in
* Enrico Weigelt weig...@metux.de [110104 16:07]:
And what exactly is the problem w/ redundant system pathes ?
They do not only include the library in question, but they include many
other libraries. As paths supplied by the user are searched in before
anything in the system path, this changes
On Mon, 3 Jan 2011 21:45:49 +, Roger Leigh rle...@codelibre.net
wrote:
IMHO, there are nowadays few (if any) compelling reasons for having a
separate /usr, and hence for having /usr at all other than as a
compatibility symlink to /. Have we actually got any reasons for
keeping it?
many
On Tue, Jan 04, 2011 at 04:47:28PM +0100, Sven Joachim wrote:
On 2011-01-04 16:33 +0100, Steve Langasek wrote:
In what way is it not already possible to symlink /usr to /?
There are packages which ship a binary /bin/foo and a symlink
/usr/bin/foo to it. Those will likely be broken, since
Steve Langasek, le Tue 04 Jan 2011 09:34:45 -0800, a écrit :
I don't agree. dpkg doesn't need to care that /usr/lib/libm.so really
unpacks to /lib/libm.so due to /usr - / symlink,
dpkg doesn't care, but shlibdeps does care, hurd-i386 has been bitten by
that enough to make us give up with /usr
On 2011-01-04 18:34 +0100, Steve Langasek wrote:
On Tue, Jan 04, 2011 at 04:47:28PM +0100, Sven Joachim wrote:
It is not possible to do the switch on upgrades anyway, at least not
while every package ships files under /usr. You can only do that when
there are no packages installed that have
On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim svenj...@gmx.de wrote:
Maybe we're talking at cross-purposes here; I was speaking about the
case of turning a directory into a symlink on upgrades, which cannot
safely be done while there are still files under it.
Thinking more about it, this
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault sthiba...@debian.org wrote:
Steve Langasek, le Tue 04 Jan 2011 09:34:45 -0800, a écrit :
I don't agree. dpkg doesn't need to care that /usr/lib/libm.so really
unpacks to /lib/libm.so due to /usr - / symlink,
dpkg doesn't care, but shlibdeps
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault sthiba...@debian.org wrote:
Steve Langasek, le Tue 04 Jan 2011 09:34:45 -0800, a écrit :
I don't agree. dpkg doesn't need to care that /usr/lib/libm.so really
unpacks to /lib/libm.so due to /usr - / symlink,
dpkg doesn't care, but shlibdeps
Olaf van der Spek, le Tue 04 Jan 2011 18:46:47 +0100, a écrit :
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault sthiba...@debian.org wrote:
Steve Langasek, le Tue 04 Jan 2011 09:34:45 -0800, a écrit :
I don't agree. dpkg doesn't need to care that /usr/lib/libm.so really
unpacks to
On Tue, Jan 4, 2011 at 7:13 PM, Samuel Thibault sthiba...@debian.org wrote:
dpkg doesn't care, but shlibdeps does care, hurd-i386 has been bitten by
that enough to make us give up with /usr - /.
Why couldn't shlibdeps be fixed?
We kept fixing it, and at some point (where it became really
On Tue, Jan 04, 2011 at 06:51:13PM +0100, Olaf van der Spek wrote:
On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim svenj...@gmx.de wrote:
Maybe we're talking at cross-purposes here; I was speaking about the
case of turning a directory into a symlink on upgrades, which cannot
safely be done
On Tue, Jan 4, 2011 at 7:29 PM, Steve Langasek vor...@debian.org wrote:
On Tue, Jan 04, 2011 at 06:51:13PM +0100, Olaf van der Spek wrote:
On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim svenj...@gmx.de wrote:
Maybe we're talking at cross-purposes here; I was speaking about the
case of turning
On Tue, Jan 04, 2011 at 07:32:06PM +0100, Olaf van der Spek wrote:
On Tue, Jan 4, 2011 at 7:29 PM, Steve Langasek vor...@debian.org wrote:
On Tue, Jan 04, 2011 at 06:51:13PM +0100, Olaf van der Spek wrote:
On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim svenj...@gmx.de wrote:
Maybe we're
Olaf van der Spek, le Tue 04 Jan 2011 19:21:18 +0100, a écrit :
On Tue, Jan 4, 2011 at 7:13 PM, Samuel Thibault sthiba...@debian.org wrote:
We kept fixing it, and at some point (where it became really not obvious
to fix it, or would have made it very cpu-consuming to solve the path
Nice write-up, you raise many good points I agree with.
Just a small remark:
On 05.01.2011 01:25, Roger Leigh wrote:
2) /usr is mounted read-only for security and safety
Mounting /usr read-only is common practice; I even do this myself
with apt-get configured to remount read-write
On Wed, Jan 05, 2011 at 03:29:08AM +0100, Michael Biebl wrote:
Nice write-up, you raise many good points I agree with.
Just a small remark:
On 05.01.2011 01:25, Roger Leigh wrote:
2) /usr is mounted read-only for security and safety
Mounting /usr read-only is common practice;
Olaf van der Spek olafvds...@gmail.com wrote:
On Sun, Jan 2, 2011 at 1:37 AM, Steve Langasek vor...@debian.org wrote:
I don't think there's much room for argument at all, the FHS definition of
/lib is pretty clear. :)
Yes, this does cause problems for autotools and the like when it
comes
On Mon, Jan 3, 2011 at 8:06 PM, Andreas Metzler
ametz...@downhill.at.eu.org wrote:
What's the problem with fixing automake?
Hello,
in a nutshell: I doubt anybody who has the knowledge to fix it cares,
and there is more to it than a
On Mon, Jan 03, 2011 at 10:33:21PM +0100, Olaf van der Spek wrote:
On Mon, Jan 3, 2011 at 8:06 PM, Andreas Metzler
ametz...@downhill.at.eu.org wrote:
What's the problem with fixing automake?
Hello,
in a nutshell: I doubt anybody who has the knowledge to fix it cares,
and there is
On Sun, Jan 2, 2011 at 1:37 AM, Steve Langasek vor...@debian.org wrote:
I don't think there's much room for argument at all, the FHS definition of
/lib is pretty clear. :)
Yes, this does cause problems for autotools and the like when it comes time
to install, since this FHS-mandated split
On 02.01.2011 04:22, Jonas Meurer wrote:
In Debian sid, as already written this is the case for the following
packages (according to amd64 Contents.gz[2]):
libnih-dev, libnih-dbus-dev, libsplashy1-dev
The following packages install development .a library to /lib in Debian
sid[3]:
Happy new year everyone.
First of all, thanks Andreas and Jonas for getting libgcrypt and libgpg-error
updated and moved to /lib.
There is one remaining issue though about the devel files, I'd like to raise.
For both libgpg-error-dev and libgcrypt11-dev you moved the .so symlink ,the *.a
and
On Sat, Jan 1, 2011 at 5:11 PM, Michael Biebl bi...@debian.org wrote:
For both libgpg-error-dev and libgcrypt11-dev you moved the .so symlink ,the
*.a
and *.la libtool files to /lib too.
My original patch [1] for libcryptsetup (#604936) handled this diffently. It
only moved the *.so.* files
On 2011-01-01 Michael Biebl bi...@debian.org wrote:
First of all, thanks Andreas and Jonas for getting libgcrypt and
libgpg-error updated and moved to /lib.
There is one remaining issue though about the devel files, I'd like to raise.
For both libgpg-error-dev and libgcrypt11-dev you moved
On Sat, Jan 1, 2011 at 17:11:17 +0100, Michael Biebl wrote:
Afaicr I've never seen this documentented somewhere to do it this way and I'm
wondering if this is indeed the agreed upon best practice and if we should
document it somehow (policy, devref, whatever).
Yes. Arguably it's covered
Hello,
On 01/01/2011 Michael Biebl wrote:
First of all, thanks Andreas and Jonas for getting libgcrypt and libgpg-error
updated and moved to /lib.
There is one remaining issue though about the devel files, I'd like to raise.
For both libgpg-error-dev and libgcrypt11-dev you moved the .so
On 01.01.2011 17:58, Jonas Meurer wrote:
Thus I guess the following is best practise:
- build with --prefix=/usr
- install .la file (if required due to reverse dependencies) and .so
link to /usr/lib (just like the build system will do)
I would add, that if there are no rdeps yet of this
On Sat, Jan 01, 2011 at 05:11:17PM +0100, Michael Biebl wrote:
For both libgpg-error-dev and libgcrypt11-dev you moved the .so
symlink ,the *.a and *.la libtool files to /lib too.
My original patch [1] for libcryptsetup (#604936) handled this
diffently. It only moved the *.so.* files to
On Sat, Jan 01, 2011 at 06:34:30PM +0100, Julien Cristau wrote:
On Sat, Jan 1, 2011 at 17:11:17 +0100, Michael Biebl wrote:
Afaicr I've never seen this documentented somewhere to do it this way and
I'm
wondering if this is indeed the agreed upon best practice and if we should
document
On 01/01/2011 Steve Langasek wrote:
On Sat, Jan 01, 2011 at 06:34:30PM +0100, Julien Cristau wrote:
On Sat, Jan 1, 2011 at 17:11:17 +0100, Michael Biebl wrote:
Afaicr I've never seen this documentented somewhere to do it this way and
I'm
wondering if this is indeed the agreed upon
On 02/01/2011 Jonas wrote:
On 01/01/2011 Steve Langasek wrote:
On Sat, Jan 01, 2011 at 06:34:30PM +0100, Julien Cristau wrote:
On Sat, Jan 1, 2011 at 17:11:17 +0100, Michael Biebl wrote:
Afaicr I've never seen this documentented somewhere to do it this way
and I'm
wondering
* Jonas Meurer jo...@freesources.org schrieb:
In case that the situation is clear, some Ubuntu packages seem to be
wrong. At least the Ubuntu libgcrypt11-dev[1] and libgpg-error-dev[2]
packages seem to install the development files to /lib.
In Debian, at least the following three packages
54 matches
Mail list logo
