Once upon a time, Chris Adams <cmadams@xxxxxxxxxx> 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@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
