Once upon a time, Chris Adams <cmadams(a)hiwaay.net> said:
One big question though: can RPM handle such a change? IIRC, when
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
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(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.