How implementation details become ABI: a case study

OK, I stand corrected - their script definitely breaks on that one... for 64bit host. Anyway, I think it's bloody obvious that what they are doing is an awful kludge.

Note that keeping the daemon running through the update is a very dubious approach; sure, the binary itself will stick around until we exit, but the rest of files in the package will get replaced, so if that daemon ever rereads them (e.g. in response to incoming request of some sort, or being asked to stop), the old binary will find new config/data/helper binaries/whatnot, with potentially spectacular results. Much safer to stop the sucker before replacing any files and restart it afterwards. And anything that does something more fancy (e.g. re-exec itself and transfer the internal state across that in one way or another) has no business using start-stop-daemon anyway.

IOW, the entire "replace files, then stop the old processes" is a bad idea. And prior to replacements there's no need whatsoever for that kind of kludges. Mind you, I'd rather do stat() on the binary we are after, then looked for /proc/*/exe with stat() giving the matching st_dev/st_ino. Without bothering with readlink() on those guys. Has an extra benefit of doing the right thing when you have multiple links to the same binary, with different processes using different names...

What they were doing is awful for a lot of reasons; sadly, that's not the criterion used in such situation ;-/ It worked for a long time, there's real-world userland code relying on it, so we get to keep it working. It's not quite the same as bug-for-bug compatibility - if nothing breaks when we fix inconsistent behaviour, we can go for it even if it was possible to write something that would break. Ditto if the code being broken is a rootkit or rootkit equivalent (i.e. relies on exploiting a security hole, by accident or not). But "the code we broke would've broken in a lot of other cases anyway" isn't an acceptable excuse.