Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Development (http://www.linux-archive.org/archlinux-development/)
-   -   merge /bin, /sbin, /lib into /usr/bin and /usr/lib (http://www.linux-archive.org/archlinux-development/640128-merge-bin-sbin-lib-into-usr-bin-usr-lib.html)

Allan McRae 03-03-2012 02:21 AM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
On 03/03/12 12:28, Dan McGee wrote:
> On Fri, Mar 2, 2012 at 7:53 PM, Tom Gundersen <teg@jklm.no> wrote:
>> /lib:
>>
>> There are also other things in /lib, I propose that
>> we temporarily patch udev, kmod and the few other packages to support
>> both /usr/lib and /lib (similarly to how systemd already works) so
>> things like udev rules and modprobe files can be moved over one
>> package at a time. Once all of this has moved, the last package to be
>> updated would be glibc that would move the linker and symlink /lib to
>> /usr/lib to maintain compat. We could then remove any transition
>> patches from udev++. For e this is sort of a no-brainer, with no real
>> risks or downsides.
>>
>> Thougts?
>
> bin/sbin/libraries, I agree with (besides perhaps shells that have
> been hardcoded for eternity, but links/symlinks will solve that).
>
> This bit I've quoted, I see absolutely no reason what so ever to screw
> around with. Why on earth do the linker, kernel modules, etc. need to
> be in /usr/lib/ at all, other than Poettering's raves and rants?

I'll just point out that Poettering actually had nothing to do with the
any proposal to do this. He just said the idea made sense. So we can
not blame him for this one!

> Hell,
> if this whole thing is supposed to "make things less confusing" and we
> have to move them anyway, then:
>
> * /lib/modules -> /kernel/modules
> * /lib/ld-2.15.so -> /linker/x86_64
> * /lib/ld-linux.so.2 -> /linker/i386
>
> Of course I'm (probably) joking here. But my point is, moving these
> things to /usr is only going to be a pain in the ass, and I see
> absolutely no gain whatsoever from the argument your presented for
> doing this in the first place.

When I first looked at hurd and saw "usr -> .", I was immediately
convinced that this was a great idea. It is simplifying the filesystem
layout in terms of where of where to look to find specific files (e.g.
is the library in /lib or /usr/lib) and makes packaging simpler (e.g. if
libfoo.so is in /lib and libfoo.a is in /usr/lib then you need symlinks
to libfoo.so in /usr/lib too). It makes little difference from a users
perspective provided the symlink is present so the old directory layout
can be used transparently.

What convinced me of putting all this in /usr rather than on / is that I
can have a separate /usr partition that is mounted read only (unless I
want to do an update). If everything from /usr gets moved to the root
(a.k.a hurd style) this would require many partitions. (There is
apparently also benefits in allowing /usr to be shared across multiple
systems, but I do not care about such a setup and I am really not sure
this would work at all with Arch.)

So I am very much for this move as it is in the category of things that
make sense to me. I also agree with the plan of dealing with /lib first
and then looking at /bin and /sbin.

Allan

Andreas Radke 03-03-2012 08:13 AM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
What about the FHS? Why should we do our own thing here again? The bad
in end user Linux experience is the incompatibility brought by
such non-standards.

And has this idea anything to do with recent Fedora changes?

IMHO we are now the next big community distro behind the commercial
players and should raise our voice more often in projects that define
future standards.

-Andy

Allan McRae 03-03-2012 08:49 AM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
On 03/03/12 19:13, Andreas Radke wrote:
> What about the FHS? Why should we do our own thing here again? The bad
> in end user Linux experience is the incompatibility brought by
> such non-standards.

This does not conflict with the FHS. e.g. the FHS only says /bin should
exist and what files should be found there. There is nothing saying
that /bin can not be a symlink to /usr/bin.

This actually will result in more cross-distro compatibility as there
will not longer be differences about where files are located. To pick
an example, /bin/awk will exist and /usr/bin/awk will exist, so either
hardcoded path will work. Note this currently happens for our gawk
package with symlinks, but only after a bug report asking for us to put
both paths sat in our bug tracker for years...

Now the changes Debian are making is an entirely different story...

> And has this idea anything to do with recent Fedora changes?

It most definitely is influenced by it. But those of us in favor of
this are not just blindly following Fedora but actually think it is a
good idea.

> IMHO we are now the next big community distro behind the commercial
> players and should raise our voice more often in projects that define
> future standards.

Sure. Anybody can join the appropriate mailing lists and influence
things like this. For example, python PEP-394
(http://www.python.org/dev/peps/pep-0394/) was essentially written due
to Arch making python3 the default python.

Allan

Pierre Schmitz 03-03-2012 08:49 AM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
Am 03.03.2012 04:21, schrieb Allan McRae:
> What convinced me of putting all this in /usr rather than on / is that I
> can have a separate /usr partition that is mounted read only (unless I
> want to do an update). If everything from /usr gets moved to the root
> (a.k.a hurd style) this would require many partitions. (There is
> apparently also benefits in allowing /usr to be shared across multiple
> systems, but I do not care about such a setup and I am really not sure
> this would work at all with Arch.)

I agree that the /usr subtree we have atm and also the distinction of
bin and sbin is not really useful and confuses more than it helps.
Especially the sbin one doesn't make any sense. So it's nice to cleanup
our filesystem and merge things together. While I don't think a
read-only /usr is of any use or even advisable I see that having
everything in /usr is more flexible; so I am fine with that.

So in short: +1 from me.

--
Pierre Schmitz, http://pierre-schmitz.com

Pierre Schmitz 03-03-2012 08:54 AM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
Am 03.03.2012 10:49, schrieb Allan McRae:
> This actually will result in more cross-distro compatibility as there
> will not longer be differences about where files are located.

Indeed. And also I don't see any great activity at the FHS project. It
seems like they more or less just add directories that are used in the
wild. So the FHS will probably have an entry for this.

--
Pierre Schmitz, http://pierre-schmitz.com

Ionut Biru 03-03-2012 04:36 PM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
On 03/03/2012 07:24 PM, Tom Gundersen wrote:
> On Sat, Mar 3, 2012 at 4:53 PM, Dan McGee <dpmcgee@gmail.com> wrote:
>> Please tell me exactly what I'm looking for, becuase I couldn't find
>> it. I read through your first email, and not once was the following
>> statement made:
>> "lib/modules is better than /lib/modules because..."
>
> In isolation many of the dirs under /lib do not make sense to move to
> /usr/lib, but if we move them all together then, /usr/lib/modules is
> better than /lib/modules because:
>
> * it increases cross-distro compatibility (due to the possibility of
> /lib being a symlink, which otherwise would not be possible)
> * it simplifies the filesystem layout (all the static stuff going under /usr)
> * it allows us to get rid of /lib as a directory, making sure that
> stuff will not "leak" back out of /usr over time
> * it does not make sense to have both /lib and /usr/lib if we can
> avoid it, we should pick one
>

I'm against moving kernel modules in any other directory because is NOT
improving cross-distro at all and mostly breaks every application that
expects /lib/modules/`unamer -r`.

Don't drop traditions and I'm ok with it.


--
IonuÈ›

Thomas Bächler 03-03-2012 04:53 PM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
Am 03.03.2012 03:52, schrieb Jan Steffens:
> On Sat, Mar 3, 2012 at 3:28 AM, Dan McGee <dpmcgee@gmail.com> wrote:
>> Why on earth do the linker, kernel modules, etc. need to
>> be in /usr/lib/ at all, other than Poettering's raves and rants?
>
> We need to empty /lib, otherwise we can't symlink it.

There is no need at all to ever symlink /lib! I would be fine with a
/lib directory that has exactly 2 symlinks (namely ld-linux.so.2 and
ld-linux-x86_64.so.2).

Also stuff like kernel modules, udev rules, and so on. Why move them at all?

The primary concern is binaries, that's where problems may occur (that's
why we would - long-term - need symlinks from /bin, /sbin and /usr/sbin
to /bin).

For libraries, we can put them whereever we want.

Thomas Bächler 03-03-2012 05:02 PM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
Am 03.03.2012 10:13, schrieb Andreas Radke:
> IMHO we are now the next big community distro behind the commercial
> players and should raise our voice more often in projects that define
> future standards.

Some of us are. One example is how Dave not only was an important force
behind fixing bugs in recent kmod and util-linux releases, but he also
influenced changes in behaviour in those projects to our advantage.

It's up to the individual to influence things their way. For instance,
although I do not know for sure, I assume that your involvement in
Libreoffice discussions has lead to improvements in their build systems
(btw, some libreoffice guys asked about you at FOSDEM in Brussels).

There are more examples. They seem insignificant, but they're not.

Matthew Monaco 03-03-2012 07:13 PM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
On 03/03/2012 10:49 AM, Tom Gundersen wrote:
> On Sat, Mar 3, 2012 at 6:36 PM, Ionut Biru <ibiru@archlinux.org> wrote:
>> I'm against moving kernel modules in any other directory because is NOT
>> improving cross-distro at all and mostly breaks every application that
>> expects /lib/modules/`unamer -r`.
>
> This is an important point: referencing /lib/modules/ will still work
> exactly as before, due to the symlink. Otherwise, this would have been
> crazy.
>
> -t


/lib -> /usr/lib/
/usr/lib/{modules,firmware} -> /kernel/{modules,firmware}/

Allan McRae 03-03-2012 09:33 PM

merge /bin, /sbin, /lib into /usr/bin and /usr/lib
 
On 04/03/12 01:53, Dan McGee wrote:
> On Sat, Mar 3, 2012 at 5:07 AM, Tom Gundersen <teg@jklm.no> wrote:
>> Not sure exactly where the serious stuff ended and the trolling began,
>> so I'll take all of it seriously.
> I was the first reply. None of this was trolling, it was legitimate gripes.
>
>> On Sat, Mar 3, 2012 at 3:28 AM, Dan McGee <dpmcgee@gmail.com> wrote:
>>> bin/sbin/libraries, I agree with (besides perhaps shells that have
>>> been hardcoded for eternity, but links/symlinks will solve that).
>>
>> Cool.
>>
>>> Why on earth do the linker, kernel modules, etc. need to
>>> be in /usr/lib/ at all
>>
>> See below.
> Please tell me exactly what I'm looking for, becuase I couldn't find
> it. I read through your first email, and not once was the following
> statement made:
> "lib/modules is better than /lib/modules because..."
>
>>> Hell,
>>> if this whole thing is supposed to "make things less confusing" and we
>>> have to move them anyway, then:
>>>
>>> * /lib/modules -> /kernel/modules
>>> * /lib/ld-2.15.so -> /linker/x86_64
>>> * /lib/ld-linux.so.2 -> /linker/i386
>>>
>>> Of course I'm (probably) joking here.
>>
>> Why not keep the linker with the other .so's? Why create new top-level
>> dirs? These three symlinks means that /lib must be a proper dir, why
>> stop it from being a symlink, and reduce compat with other distros
>> (once some, but not all, start moving udev rules and the like from
>> /lib to /usr/lib)?
>
> Fine, take the linker and move it to /usr/lib (Doesn't this require
> patching the kernel?). But that wasn't the point of my typing here,
> and you seemed to get stuck on that.
>
> But you can truely tell me, with a straight face, the following things
> belong in /usr/lib, let alone /lib? My whole point of this "troll" was
> to point out we're spending time and pain moving from bad location A
> to bad location B- shouldn't we just take a step back, stop following
> Fedora blindly, and point out that some of this makes no sense at all?
>
> * Kernel modules- these are "libraries" only in the strictest sense,
> but even systesm sharing a common /usr have no need to share kernel
> modules (or might be able to, if they are booting from different
> kernels). So, proposed location- /kernel/modules.
> * Kernel firmware- architecture agnostic. Most of this doesn't belong
> in a library directory as it isn't executable code per se by the OS
> itself; it is also architecture agnostic. Proposed location-
> /kernel/firmware.
> * Udev rules- once again, this is architecture agnostic, not
> executable, etc. Why is this in lib?
> * /lib/depmod.d/search.conf is owned by kmod 5-4- WTF is this, besides
> a funny joke? Configuration in /lib?
> * /lib/device-mapper/, /lib/multipath/, /lib/security/- no problems at
> all with moving, this is exactly the type of move I do agree with, as
> it is a logical separation that makes no sense.
>
>> Of course, you know all that, I should not fall for your trolling.
>>
>>> But my point is, moving these
>>> things to /usr is only going to be a pain in the ass, and I see
>>> absolutely no gain whatsoever from the argument your presented for
>>> doing this in the first place.
>>
>> Maybe I should have been clearer in the justification for moving
>> non-libs from /lib to /usr/lib.
>>
>> The subdirs of /lib are (at least):
>>
>> device-mapper
>> depmod.d
>> initcpio
>> modprobe.d
>> security
>> systemd
>> udev
>> firmware
>> modules
>>
>> Littering / with non-standard dirs "just because" is obviously not
>> going to happen, so they either stay put, or move to /usr/lib. Based
>> on current practices, I think they all belong there. Do you have any
>> strong arguments to the contrary?
> See above.
>
>> Lastly, as I mentioned before, I think having all of the static stuff
>> under /usr, is a lot cleaner than our current layout (and in the
>> future it might allow cool uses such as shared /usr among virtual
>> machines, hosts, chroots, whatever).
> /lib is one directory, as is /usr. That honestly doesn't seem like all
> that much of a hassle to me. Ideal? No. But I'm not sure where the
> "littering" of non-standard dirs in '/' comes into place.
>
> Am I completely serious about the creation of a new /kernel directory?
> Not really, especially as there seems to be an allergy toward
> top-level directory creation (unless their name is /run). But hell,
> throw it in /boot then! No new directory created. My point was, I just
> don't see how having kernel modules, firmware, etc. in /usr/lib makes
> any sense whatsoever.
>
>> The firmware and modules dir might need some planning to get right,
>> but this was meant to be about the principle, rather than the
>> implementation, so I won't comment on that.
>
> Well when you're telling people in a follow-up email "Contributions
> welcome. Especially in the form of rebuilds ;-)", somehow I felt like
> commenting on the implementation wasn't off-limits...


I have read all this multiple times and I have no idea whether you
actually object to the proposal or not...

I agree that /usr/lib/modules is just as crap as /lib/modules. But
moving them to /usr does not make that situation worse, and it achieves
what I want to achieve with this move - getting all static content into
a single root directory.

If you want additional changes beyond the /usr move, I suggest preparing
another proposal to do so. I find this a bit like suggesting we should
not have release pacman with signing support because hooks are not
implemented. I do not like seeing progress on one issue being blocked
because of an independent issue with no real plan that can be handled
independently.

Allan


All times are GMT. The time now is 01:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.