merge /usr like it's 2012

[lrusak]

This is more or less for aesthetic purposes for LE however, we should get with the times.

This builds and runs as I have tested on an RPi2, but this isn't till LE9.0 anyway.

reference:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
though the cases aren't explictly relevant to us
etc...

There are symlinks for:

/lib -> /usr/lib
/bin -> /usr/bin
/sbin -> /usr/sbin

These are needed for proper operation of the system, they also are there so we don't have to change every hardcoded /bin/sh to /usr/bin/sh although I have already done that in another branch.

Some people may not be in favour of this as they may deem it unnecessary however, I think it is time to conform to modern OS's and shove things around when we get to the LE9.0 merge window.

[stefansaraev]

be very, very careful. busybox installs a bunch of symlinks. you may have binaries provided by other packages silently replaced (and failing at runtime), or busybox links replaced...

btw. none of the above mentioned "why /usr is broken" arguments applies to LE.

EDIT: fyi, I tried this usr merge in my fork (never pushed it..) half an year ago, in a bit different way than yours, and decided it's not worth the trouble, because it fixed nothing for me, anyway..

[lrusak]

good to know, default shows

LibreELEC:~ # ls /bin/ /usr/bin | sort | uniq -d
env
mkdir

both are symlinks

LibreELEC:~ # ls -l /bin/env /usr/bin/env
lrwxrwxrwx    1 root     root             7 Oct  2 23:29 /bin/env -> busybox
lrwxrwxrwx    1 root     root            12 Oct  2 23:29 /usr/bin/env -> /bin/busybox
LibreELEC:~ # ls -l /bin/mkdir /usr/bin/mkdir
lrwxrwxrwx    1 root     root             7 Oct  2 23:29 /bin/mkdir -> busybox
lrwxrwxrwx    1 root     root            12 Oct  2 23:29 /usr/bin/mkdir -> /bin/busybox

[lrusak]

Rebased and added a couple commits, I'll build test this again and then we can hopefully get this into @MilhouseVH builds

[lrusak]

I've build and run tested the on RPi2, Odroid_C2 and Generic and it works.

@LongChair will this mess you guys up at all?

[LongChair]

not sure yet, would need to try.
Would probably require to adjust some our our packages that might also install stuff in /usr/lib and such.

[lrusak]

@MilhouseVH thoughts?

[MilhouseVH]

Not sure why but after #1004, I now have build faliures on RPi/RPi2/Generic when building Python: http://sprunge.us/gVHj (all clean builds)

Maybe there's a conflict with this PR? No idea really, but reverting #1004 (while building with this PR) fixes the issue.

[MilhouseVH]

My vanilla nightly (no unmerged commits) also failed while building Python, so this PR is not the cause of the failure - #1004 is just bad. I'll revert #1004 and try another clean vanilla build.

[MilhouseVH]

Not sure how I closed this...!

[lrusak]

Ready to go unless any objections.

[ozolli]

Not sure at all, but is this build failure (on Debian 8.6) related to this commit ?
Build log : http://sprunge.us/McjN

[CvH]

@ozolli did you tried a fresh build ? (make clean btw with nuking the ccache make distclean)

[ozolli]

Yes on a brand new install. For now it compiles fine on tag 7.90.009, although with some warnings where it failed on Master.

[lrusak]

that looks like the error @piotrasd was experiencing

[piotrasd]

yes same, i was on ubuntu 14.04.4 LTS after upgrade to 16.04 problem gone,

[ozolli]

Is it possible that the error comes from my compiling machine not being "usr merged" itself?

[lrusak]

@ozolli no, it looks like you need to update your machine's glibc

[piotrasd]

i just do it this, even with force update glibc, but i got before and after some segfault in dmesg from glibc, please check your dmesg ;)

[ozolli]

@lrusak libc6 v2.19-18 is the latest available and is installed. Too old?

[lrusak]

@ozolli I would assume so :)

[ozolli]

Debian Testing provides libc6 v2.24-7, is it enough or it is useless to upgrade too ?
Edit: Ubuntu 16.04 has libc6 v2.23 so I guess it would do it.

[piotrasd]

yes i have 16.04 and is fine

[ozolli]

I confirm it compiles fine with Debian Testing.

[InuSasha]

I had found a hint.
I drop the LD_LIBRARY_PATH from environment before the make install runs, and it works.
It looks like the ln, rm cames from the host-system and try to use the libc from the host-build.
May we should build an own host ln, rm, etc.

[stefansaraev]

make sure LD_LIBRARY_PATH is always unset in LE's buildsystem. you dont need it for anything. also make sure your host tools are always compiled static if possible.

hint: https://github.com/LibreELEC/LibreELEC.tv/blob/master/config/path#L203-L205 replace with "unset LD_LIBRARY_PATH"

[InuSasha]

i have no LD_LIBRARY_PATH set in my enviroment. The LD_LIBRARY_PATH from LE is problematic, at this point.
Other host-tools will may need it, but build all host tools with rpath or static linked should able us to drop the LD_LIBRARY_PATH at this point. or build own host-coreutils in busybox

edit:
ok i see, there is no libc in host-build... but why ln breaks with segfault (and not, without LD_LIBRARY_PATH).
But I tested to build busybox:host with coreutils, and util-linux builds fine (under debian stable)