On Sun, 26 May 2013 11:20:25 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> It is *easy*. > > ln -s /sbin/newinit /sbin/init.new > mv /sbin/init.new /sbin/init > > Easy and atomic. The inconsistency potential is similar to one given > by init upgrades. Yet we don't do anything magical to defer init > upgrade until reboot, and that's why the upgrades go smoothly. Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. > > I think that safest way not using wrapper is to stop all services > > and keep only mounted /, than change things (symlinks,configuration > > update) and reboot. > > This can be done two ways. > > One is hacking into init (RC) reboot procedure. It's fragile, it needs > to be fit into the right moment and I'm not sure if all inits will > handle this without actually needing to patch the code. And in the > end, the init gets replaced before init stops working anyway. You're making things way more complex than a wrapper would do. I'm not a fan of using the words "hacking", "fragile" and "not sure" for selling an approach; so, why were you suggesting the symlink approach? > The other is going beside init and directly into the reboot. This > either requires kernel hacking (please don't!) Yes, please don't, it's against our general objectives. http://www.gentoo.org/proj/en/kernel/maintenance.xml#doc_chap3 Furthermore, even if you would consider this then you can't be guaranteed that everyone uses genpatches; and I don't think we would want this in the eclass either, its users will very likely object. > or hacking the reboot procedure in init code. And of course > remounting R/W, then writing, remounting back... I don't think patching them is a reliable approach; it steps away from being loosely coupled and therefore makes it harder to understand, you are changing multiple things at once and introduce a maintenance burden. With a wrapper, you don't have a problem with any of those... Loose coupling, high cohesion. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
