From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-July/017266.html | 141 +++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-July/017266.html (limited to 'zarb-ml/mageia-dev/2012-July/017266.html') diff --git a/zarb-ml/mageia-dev/2012-July/017266.html b/zarb-ml/mageia-dev/2012-July/017266.html new file mode 100644 index 000000000..fffaa21b6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-July/017266.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] Planning the /usr move + + + + + + + + + +

[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
+ -- cgit v1.2.1