[arch-dev-public] final leg of /lib removal

newer
[arch-dev-public] Signoff report...

older
[arch-dev-public] Signoff report...

Dave Reisner

3 Jul 2012 3 Jul '12

5:41 p.m.

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

Show replies by date

Thomas Bächler

3 Jul 3 Jul

5:48 p.m.

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?

Dave Reisner

6:05 p.m.

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

Thomas Bächler

6:11 p.m.

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.

Dave Reisner

6:22 p.m.

On Tue, Jul 03, 2012 at 06:11:16PM +0200, Thomas Bächler wrote:

...

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.

No offense, but you're a bit late to be trying to shoot this down only now. Perhaps you recall Tom's post (and ensuing discussion) from a few months ago: http://www.mail-archive.com/arch-dev-public@archlinux.org/msg19028.html With a followup: http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022756.htm... Maybe the wiki page that detailed the plan: https://wiki.archlinux.org/index.php/DeveloperWiki:UsrMove Or when we started on this with todolist 143: https://www.archlinux.org/todo/143/ And did more of this with todolist 148: https://www.archlinux.org/todo/148/ What's the point of doing 95% of this and then polishing it off with some silly hack? /lib64 is already going away and turning into a symlink with the glibc-2.16 package in [staging]. d P.S. i686 rebuilds are done -- I've moved this all to brynhild to avoid the bandwidth restrictions on gerolde: http://pkgbuild.com/~dreisner/linux-usrmove/

Thomas Bächler

4 Jul 4 Jul

10:18 a.m.

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.

...

Perhaps you recall Tom's post (and ensuing discussion) from a few months ago:

I remember the discussion and the plan. I just still don't think it's a good plan. Didn't I say something back then? Maybe not.

Allan McRae

10:36 a.m.

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

Tom Gundersen

3 Jul 3 Jul

7:36 p.m.

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

Dave Reisner

7:48 p.m.

On Tue, Jul 03, 2012 at 07:36:48PM +0200, Tom Gundersen wrote:

...

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

As a (lazy) stop-gap measure, yes you probably could just move the module dir. I offer no warranty on this method, though. Testing on my side is going well so far... I've upgraded a bunch of VMs with both the -ARCH and -lts kernels and haven't run into any unforeseen problems yet. Working on modules in extra now... d

Dave Reisner

4 Jul 4 Jul

2:55 a.m.

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

4313

Age (days ago)

4314

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Allan McRae
Dave Reisner
Thomas Bächler
Tom Gundersen

[arch-dev-public] final leg of /lib removal

tags

participants (4)