'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/
