UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)

Chris Adams cmadams at hiwaay.net
Thu Oct 27 18:35:01 UTC 2011


Once upon a time, Chris Adams <cmadams at hiwaay.net> said:
> One big question though: can RPM handle such a change?  IIRC, when the
> switch from /etc/rc.d/init.d to /etc/init.d was made, initially
> everything was going to be moved and the old paths symlinked for a few
> releases.  However, there was some problem with RPM that couldn't handle
> switching an existing directory to a symlink, so that change was reduced
> to introducing /etc/init.d as a symlink.  How will upgrades be handled
> if this feature goes through?

I haven't seen this part addressed, and the more I think about it, the
more I think it may be a show-stopper for upgrades.

IIRC the problem is that if there are any files in /bin, RPM can't
replace the directory with a symlink.  There could be files from
third-party RPMs, Fedora RPMs that have been retired but people still
have installed, or from local changes/customizations.

There is also a problem with the order things are done.  RPM can't
replace /bin until all RPMs such as bash are updated to versions using
/usr/bin, but as soon as you install that bash, /bin/sh %post scripts
are broke until /bin is symlinked.

For example, if you use the old-style network initialization (instead of
NM), the way to do pre/post config per interface is with
/sbin/ifup-pre-local and /sbin/ifup-local.  If an admin has created
those files, RPM can't replace /sbin with a symlink to /usr/sbin AFAIK.

This would also apply if somebody added firmware manually to
/lib/firmware or built a local kernel and installed modules to
/lib/modules.

The only way I see to make this work would be to put a change directly
into anaconda (before it starts installing RPMs), but then you'd break
anybody that tried to "yum upgrade" from an older release (and there are
always people that do that).  Any anaconda work-around for this would
also have to handle filename conflicts among locally-created files (e.g.
/bin/foo and /usr/bin/foo).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


More information about the devel mailing list