[Mageia-dev] Planning the /usr move

Colin Guthrie mageia at colin.guthr.ie
Wed Jul 11 13:52:17 CEST 2012


Hi,

This is just a message regarding the upcoming /usr move.

The good news is that most of the hard work is already done by Fedora folk.

There is still a bit to do but the process is actually quite simple.

The steps are as follows:
 1. Release a dracut package that is capable of running the usermove on
boot (or current package should be fine).
 2. Add a patch to RPM that introduces a new check that must pass before
a given RPM can be installed.
 3. Create a new "filesystem" build that uses this check.


The above process ensures that the new "filesystem" package cannot be
installed on existing systems with the old layout.

Several other packages will be subsequently broken (some packages ship
their binaries in /bin but symlink them to /usr/bin  but when /bin is
itself a symlink to /usr/bin, they package ultimately conflicts with
itself!). We need to identify such packages and fix them and have them
ready to go. In order to do the transition correctly, we may need to fix
them first, build them and then wait until all such packages are fixed,
THEN update the filesystem rpm and then rebuild all such packages with a
dep on the filesystem > x package. This might be needed to avoid any
problems on the build system chroots.

During this window when packages are updated but do not depend on the
new filesystem, some things might break as hard-coded paths may no
longer work. I don't think this will affect the chroots and build system
too much, but it might affect real systems if people do an auto-update.
Therefore I'd propose to do this work at a time when people can be
warned and there are a few of us about to fix things up on the chroots
should things go wrong :)

Once all this preparation work is done, users will find they cannot
install the filesystem and the various packages that depend on it.

In order to upgrade I will push a new package
"mageia-filesystem-update". This package will create a new initrd via
dracut and add a menu option in the boot loader that will trigger
dracut's built in migration routine. Users will then be requested to
reboot using this option and then run the package updates.

The new filesystem rpm can then remove this conversion package
automatically (via conflicts, not obsoletes) if we think that's wise to
do such housekeeping.



In a set of follow up emails I'll post some results from investigations
of what packages are affected by the change (preliminary checks are
quite promising in that there are not too many packages that will need
fixed - IIRC fedora found ~30 packages which isn't too bad).

Please let me know if the process is not clear or you think I've missed
something.

Col




-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/



More information about the Mageia-dev mailing list