[Mageia-dev] Planning the /usr move

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 11/07/12 14:10 did gyre and gimble:
> 'Twas brillig, and Colin Guthrie at 11/07/12 12:52 did gyre and gimble:
>> 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).
> 
> OK, here are some results from a small script I wrote.
> 
> Firstly I ran two commands:
> 
> urpmf ^/sbin | sort -u >slash-sbin.txt
> urpmf ^/bin | sort -u >slash-bin.txt
> 
> 
> 
> Then ran the attached script on each which takes each package name and
> tries to find any conflicting files in /usr in other packages.
> 
> Here are the results:
> 
> /sbin:
> 
> alsa-utils:self
> bluez:self
> davfs2:self
> info-install:dpkg
> iputils:self
> libselinux-utils:self
> ncpfs:self
> sound-scripts:self
> util-linux:self
> xfsdump:self
> zapata:dahdi-tools
> 
> 
> /bin:
> 
> coreutils:heimdal-workstation
> findutils:self
> fuse:self
> gawk:self
> gettext-base:self
> gzip:self
> kbd:self
> kmod:self
> lsb-release:self
> open:self
> pdksh:self
> plymouth:self
> procps:self
> sound-scripts:self
> util-linux:heimdal-login shadow-utils
> 
> 
> 
> As you can see the results are quite easy. Most of them "self conflict"
> which is a trivial fix in those packages.
> 
> The ones that are actually mildly complicated are:
> 
> info-install:dpkg
> zapata:dahdi-tools
> coreutils:heimdal-workstation
> util-linux:heimdal-login shadow-utils
> 
> The heimdal-login issues should be mostly OK, as the package itself
> conflicts with util-linux, but the -workstation provides it's own "su"
> in /usr/bin. This is likely to be a problem in itself as I'm not sure
> any package can conflict with core-utils!! I don't know anything about
> heimdal, so anyone with expertise in the ins and outs of this should
> speak up!
> 
> The Only other real problem is that we currently use "login" from
> shadow-utils (by virtue of it being in /usr/bin) but a /bin/login is
> provided by util-linux.
> 
> It seems fedora use the util-linux one and remove binaries from
> shadow-utils they don't use. If no-one has any strong opinion or
> knowledge here I'll just follow that pattern.
> 
> http://pkgs.fedoraproject.org/gitweb/?p=shadow-utils.git;a=blob;f=shadow-utils.spec;hb=HEAD
> 
> 
> 
> I've not done checks in the various lib packages (for /lib and /lib64)
> but I suspect there will be less complications there anyway and mostly
> just self-conflicts.

OK, so I've now down more analysis and the following should be a
complete list of package which have issues relating to the same files
existing in / vs /usr (46 packages in total):

 acl-2.2.51-3.mga2.src.rpm
 alsa-utils-1.0.25-4.mga2.src.rpm
 attr-2.4.46-1.mga2.src.rpm
 bluez-4.101-1.mga3.src.rpm
 coreutils-8.17-1.mga3.src.rpm
 davfs2-1.4.6-1.mga1.src.rpm
 db47-4.7.25-8.mga1.src.rpm
 db48-4.8.30-8.mga2.src.rpm
 db51-5.1.25-5.mga2.src.rpm
 db52-5.2.36-2.mga3.src.rpm
 dmapi-2.2.10-3.mga1.src.rpm
 filesystem-2.1.9-17.mga2.src.rpm
 findutils-4.5.10-1.mga2.src.rpm
 fuse-2.8.7-1.mga2.src.rpm
 gawk-4.0.1-1.mga2.src.rpm
 gcc-4.7.1-3.mga3.src.rpm
 gettext-0.18.1.1-2.mga2.src.rpm
 grub-0.97-32.mga1.src.rpm
 gzip-1.5-1.mga3.src.rpm
 iputils-20101006-3.mga2.src.rpm
 kbd-1.15.3-1.mga2.src.rpm
 kmod-8-1.mga3.src.rpm
 libselinux-2.0.78-3.mga1.src.rpm
 libtermcap-2.0.8-51.mga3.src.rpm
 libusb1-1.0.9-1.mga2.src.rpm
 libusb-compat-0.1.4-1.mga3.src.rpm
 lsb-4.1-12.mga3.src.rpm
 lsb-release-2.0-37.mga3.src.rpm
 ncpfs-2.2.6-12.mga3.src.rpm
 ncurses-5.9-6.mga2.src.rpm
 nspr-4.9.1-1.mga3.src.rpm
 nss-3.13.5-1.mga3.src.rpm
 open-1.4-21.mga1.src.rpm
 pcre-8.21-1.mga2.src.rpm
 pdksh-5.2.14-29.mga1.src.rpm
 plymouth-0.8.5.1-1.mga3.src.rpm
 procps-3.2.8-6.mga1.src.rpm
 readline-6.2-4.mga2.src.rpm
 sound-scripts-0.62-9.mga3.src.rpm
 systemd-186-1.mga3.src.rpm
 texinfo-4.13a-5.mga3.src.rpm
 util-linux-2.21.2-1.mga3.src.rpm
 xfsdump-3.1.0-1.mga2.src.rpm
 xz-5.0.4-1.mga3.src.rpm
 zapata-1.4.12.1-2.mga2.src.rpm
 zlib-1.2.7-3.mga3.src.rpm



My plan will be to rebuild each of them locally without any kind of
conflicts (most of them self conflicts as I mentioned previously).

Then I will update the filesystem package and build it locally with the
rpm test so it cannot be installed unless the filesystem is in a
suitible state, do the filesystem conversion via dracut, then upgrade
filesystem package and all the rebuilt packages.

Assuming my system is fine, I will then submit all the packages above
for build on the buildsystem, update the filesystem package on the
buildsystem, then rebuild all the above packages again but with an
additional Requires(pre): filesystem >= $whatever-it-is.


Assuming it all works for me, would others be willing to test (on
x86_64) the packages I'll build?  I'll publish them to a custom repo,
along with detailed instructions on the dracut procedure, for running
the upgrade.


Cheers

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/