* Roger Leigh 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 (lib|bin|sbin) dirs, why
* Bernhard R. Link 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 a user supli
On Wed, 5 Jan 2011 16:42:29 +0100
Olaf van der Spek wrote:
> On Wed, Jan 5, 2011 at 3:15 PM, Roger Leigh 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 i
On Wed, Jan 5, 2011 at 3:15 PM, Roger Leigh 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 feature such as sep
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 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.
On Wed, Jan 5, 2011 at 1:18 PM, Roger Leigh 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 /usr as a symli
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 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 "bigge
Mike Hommey (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.
signature.asc
Description: D
On Wed, Jan 5, 2011 at 1:25 AM, Roger Leigh 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 that would sol
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 securit
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 commo
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-writ
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 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
> > ambiguities), we got t
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 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 wrote:
> >> > Maybe we're talking at cross-purposes h
On Tue, Jan 4, 2011 at 7:29 PM, Steve Langasek 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 wrote:
>> > Maybe we're talking at cross-purposes here; I was speaking about the
>> > case of turning a directory into a symli
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 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
On Tue, Jan 4, 2011 at 7:13 PM, Samuel Thibault 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 not obvio
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 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
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault 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 does care, hurd-
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault 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 does care, hurd-
On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim 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 cannot be done e
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 th
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 /us
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, sin
On Mon, 3 Jan 2011 21:45:49 +, Roger Leigh
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 sysadmins including me
* Enrico Weigelt [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 the order the sys
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 /
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 n
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
* Bernhard R. Link 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 something else, or
* Andreas Metzler 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 not.
Another solution woul
On Tue, Jan 4, 2011 at 2:40 PM, Tollef Fog Heen 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 condition?
Olaf
]] Olaf van der Spek
| On Tue, Jan 4, 2011 at 1:42 PM, Tollef Fog Heen 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 non-contrived ex
On Tue, Jan 4, 2011 at 1:42 PM, Tollef Fog Heen 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 debian-devel-requ...@lists.de
]] Olaf van der Spek
| On Tue, Jan 4, 2011 at 9:38 AM, Tollef Fog Heen 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-conf
* Olaf van der Spek [110104 11:20]:
> On Tue, Jan 4, 2011 at 9:38 AM, Tollef Fog Heen 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.
> >
> > Fi
On Tue, Jan 4, 2011 at 9:38 AM, Tollef Fog Heen 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 shouldn't.
]] 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 se
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
> 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
On Mon, Jan 3, 2011 at 8:06 PM, Andreas Metzler
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
> --with-stuff-usually-in-libdir-but-we-want-it-below-urs=/usr/lib.
> Installing
Olaf van der Spek wrote:
> On Sun, Jan 2, 2011 at 1:37 AM, Steve Langasek 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-
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]:
> lib
On Sun, Jan 2, 2011 at 1:37 AM, Steve Langasek 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 between /usr/lib
* Jonas Meurer 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 need to be fixed:
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
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
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
> > d
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 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 t
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
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
On 2011-01-01 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
> syml
On Sat, Jan 1, 2011 at 5:11 PM, 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 /lib an
53 matches
Mail list logo
