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

Harald Hoyer harald.hoyer at gmail.com
Fri Oct 28 09:47:04 UTC 2011


On 10/27/2011 08:35 PM, Chris Adams wrote:
> 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).
>

The strategy is:

- Replace binaries in /bin /sbin /usr/sbin /lib /lib64 with symlinks to 
their counterpart in /usr. Symlinking is done in rpm %post. Symlinks are 
part of the filelist with %ghost.
- As soon as one of these directories _only_ contains symlinks, it can 
be removed completly and replaced by a symlink.
- The removal of the directories can either happen after the upgrade via 
anaconda, or within the initramfs while booting or in shutdown.
- Fresh installations will get the toplevel symlinks immediatly and no 
%ghost  symlinks are created

Read the rpm snippet on the feature page, please.


More information about the devel mailing list