Am 03.07.2012 17:41, schrieb Dave Reisner:

BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module tools for users with their own kernels. If you do not rebuild your kernel after pulling in the new kmod, you're going to have a bad time. See the paste link above for inspiration.

This worries me, a lot. Can't we get a smoother upgrade path?

Am 03.07.2012 18:05, schrieb Dave Reisner:

On Tue, Jul 03, 2012 at 05:48:43PM +0200, Thomas Bächler wrote:

...

Am 03.07.2012 17:41, schrieb Dave Reisner:

...

BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module tools for users with their own kernels. If you do not rebuild your kernel after pulling in the new kmod, you're going to have a bad time. See the paste link above for inspiration.

This worries me, a lot. Can't we get a smoother upgrade path?

Not really.

We could patch all things using kmod (udev and kmod's tools) to look in both /usr/lib as well as /lib, but that's ugly and doesn't really do us any good.

We could make this rebuild coincide with the glibc rebuild to get rid of /lib, but you can't install glibc with /lib as a symlink until /lib/modules doesn't exist. The only way /lib/modules doesn't exist is if people with custom kernels rebuild them into /usr/lib/modules.

Okay. Why do we want /lib as a symlink to /usr/lib anyway? You could have the directory /lib, only containing the symlinks for ld-linux.so.2 -> /usr/lib/ld-linux.so.2 and ld-linux-x86_64.so.2 -> /usr/lib/ld-linux-x86_64.so.2 (and, of course /lib64/ld-linux-x86_64.so.2 for compatibility). I don't see any advantage in having the symlink /lib -> /usr/lib, except a harder upgrade path where so many things could go wrong.

On Jul 3, 2012 5:41 PM, "Dave Reisner" wrote:

Hey all,

*** If you use a custom kernel, this will affect you. Please read the big scary note at the end ***

I'm taking today to work on the last roadblock before Allan can move glibc out of /lib. This basically consists of a rebuild of:

- kmod (to drop our local patch) - linux, linux-lts (diff for linux here: http://paste.xinu.at/LLd/) - all OOT kernel modules (for /usr/lib/modules/extramodules-*) - bash-completion (temp patch until /lib is a symlink:

http://paste.xinu.at/xEs/)

I'll be doing this all locally to avoid building against allan's new toolchain in [staging]. This will hopefully all hit [testing] by the end of the day. You know where to find me if you have any questions or angry rants.

If you'd like to do some early testing, I'm leaving the rebuilt kmod and kernel packages on gerolde:

http://dev.archlinux.org/~dreisner/linux-usrmove/

(i686 packages are lagging behind at the moment)

BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module tools for users with their own kernels. If you do not rebuild your kernel after pulling in the new kmod, you're going to have a bad time. See the paste link above for inspiration.

Is a rebuild really necessary? I thought all that was needed was to move the modules from / to /usr? Thanks for picking this up! I'll help out with testing in a couple of hours. Tom

On Tue, Jul 03, 2012 at 11:41:08AM -0400, Dave Reisner wrote:

Hey all,

*** If you use a custom kernel, this will affect you. Please read the big scary note at the end ***

I'm taking today to work on the last roadblock before Allan can move glibc out of /lib. This basically consists of a rebuild of:

- kmod (to drop our local patch) - linux, linux-lts (diff for linux here: http://paste.xinu.at/LLd/) - all OOT kernel modules (for /usr/lib/modules/extramodules-*) - bash-completion (temp patch until /lib is a symlink: http://paste.xinu.at/xEs/)

I'll be doing this all locally to avoid building against allan's new toolchain in [staging]. This will hopefully all hit [testing] by the end of the day. You know where to find me if you have any questions or angry rants.

If you'd like to do some early testing, I'm leaving the rebuilt kmod and kernel packages on gerolde:

http://dev.archlinux.org/~dreisner/linux-usrmove/

(i686 packages are lagging behind at the moment)

BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module tools for users with their own kernels. If you do not rebuild your kernel after pulling in the new kmod, you're going to have a bad time. See the paste link above for inspiration.

Cheers! Dave

This is all complete, and is slowly moving into [testing] over the next half hour or so. Final rebuild list looks like this: kmod linux linux-lts bash-completion fcpci fcpcmcia nvidia nvidia-lts lirc cdfs ndiswrapper r8168 r8168-lts rt3562sta vhba-module virtualbox-modules virtualbox-modules-lts open-vm-tools-modules is a pain in the butt and has NOT been rebuilt yet. I'll get to this tonight but just a heads up that there will be some sort of a lag period before this is updated. Again, please heed the warning from my original message if you're a custom kernel user. If you can't immediately rebuild your kernel, a quick *temporary* solution is to either move the module dir yourself or symlink /usr/lib/modules back to /lib/modules. This *must* be done in the near future (ominous!). cheers, Dave

On 04/07/12 18:18, Thomas Bächler wrote:

Am 03.07.2012 18:22, schrieb Dave Reisner:

...

...

Why do we want /lib as a symlink to /usr/lib anyway? You could have the directory /lib, only containing the symlinks for ld-linux.so.2 -> /usr/lib/ld-linux.so.2 and ld-linux-x86_64.so.2 -> /usr/lib/ld-linux-x86_64.so.2 (and, of course /lib64/ld-linux-x86_64.so.2 for compatibility).

I don't see any advantage in having the symlink /lib -> /usr/lib, except a harder upgrade path where so many things could go wrong.

No offense, but you're a bit late to be trying to shoot this down only now.

Not trying to shoot anything down, I am just confused why the upgrade path here was not made smoother. This will lead to problems and shitstorms, and you know it.

Note: the upgrade is simple when using supported packages... We don't rebuild peoples packages for library soname bumps. Why would this be any different? Allan