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

[Geert Hendrickx]

On Tue, Jul 03, 2012 at 14:18:07 -0400, Dave Reisner wrote:
> Worst case scenario, users of custom kernels can:
> 
> - manually move /lib/modules/mycustomkernel to /usr/lib/modules/ until
>   they can do a proper rebuild.
> - boot a stock -ARCH kernel (you DO have it listed as a fallback,
>   right?) until they can do a proper rebuild.
> 
> Emphasis on "until they can do a proper rebuild". It's important that
> this all gets done before we introduce a new glibc package that wipes
> out /lib entirely. If you have custom kernel bits lying around in
> /lib/modules, it's going to block the eventual glibc upgrade that brings
> this (no, it won't be immediately with 2.16).
> 
> dave



What will be the situation for VM users, where /lib/modules is managed
externally by the VM hoster, but the kmod package by the VM customer?

After moving the current modules manually, will we get away with a symlink
/lib/modules -> /usr/lib/modules to support future kernel upgrades?

(the kernel upgrade procedure will typically take down the VM, mount the
filesystem on the host directly to install new modules, and boot the VM
with the new kernel, so no opportunity for the VM customer to manually
interact before boot.)


	Geert


-- 
geert.hendrickx.be :: geert at hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!