FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 03-03-2012, 02:53 PM
Dan McGee
 
Default merge /bin, /sbin, /lib into /usr/bin and /usr/lib

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...

-Dan
 
Old 03-03-2012, 04:24 PM
Tom Gundersen
 
Default merge /bin, /sbin, /lib into /usr/bin and /usr/lib

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

> 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?

It seems that your argument has nothing to do with /usr v /, but more
with */lib v <something else>. You have several valid points, but the
way I see it is that we don't have the resources to diverge
significantly from all our upstreams. Hence, the only choice we have
is between /lib and /usr/lib (unless upstream can be convinced
otherwise).

> * 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.

For this to happen, the first step would be to convince the kmod and
udev maintainers. My impression is that the attitude is that /usr
should contain everything that is the sole domain of the package
manager. So you probably will have to convince people that this does
not include the kernel.

> * 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.

Same as above (but here only udev to convince). Maybe
/usr/share/firmware would be an easier sell.

> * 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?

Having configuration files in /run/<pkgname>, /etc/<pkgname> and
/usr/lib/<pkgname> is getting relatively widespread. Personally, I
think this design is very useful, though I don't know (care) why
/usr/lib was chosen over some other dir in /usr. Whatever happens,
let's make sure we keep consistency between apps and between distros
(so to change this would be very hard indeed).

> * /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.

Great :-)

> /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.

I was thinking of your proposal of introducing /kernel and /linker.
One dir is not to bad, and /lib is not nonstandard, so that's not what
I had in mind at all.

> My point was, I just
> don't see how having kernel modules, firmware, etc. in /usr/lib makes
> any sense whatsoever.

The point is to get rid of the separation of /usr/lib and /lib. The
most obvious way to do this is to merge them, not to spread the
contents into other destinations.

>> 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...

Nothing is off limits. I was just stating that I am aware of the
issue, but chose not to comment on it yet (to keep the discussion on
track).

I certainly don't want to appear to rush into anything. My
"contributions welcome" comment should be seen in the context of the
wiki. It is clearly stated that some things are ready to be worked on
(the libs stuff we all agree on), some are not ready yet, and others
need further discussion (/lib/modules) .

Cheers,

Tom
 
Old 03-03-2012, 04:49 PM
Tom Gundersen
 
Default merge /bin, /sbin, /lib into /usr/bin and /usr/lib

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
 

Thread Tools




All times are GMT. The time now is 07:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org