On Wed, Aug 08, 2012 at 05:48:35PM +0100, Roger Leigh wrote: > On Wed, Aug 08, 2012 at 09:28:03AM -0700, Russ Allbery wrote: > > Yes, we could file bugs and go to the work of moving things and leaving > > symlinks behind to not break other things, but that's a lot of work. And > > it's ongoing work to keep things sorted into the right place. Whereas if > > we moved everything and left a symlink behind, that's way more work in the > > short run but then we would be done and no one would have to think about > > the distinction again. > If we did want to do a blanket move of everything in /sbin to /bin > (and for /usr/sbin to /usr/bin), we could do this in a single operation > in e.g. base-files. It wouldn't require any path changes in individual > packages, but we would need to fix any name clashes first, and also to > bail out if any were found during the upgrade. It should be possible to > do entirely atomically as well if we hardlink the binaries, and then > replace the dir with a symlink. You can't replace a directory with a symlink atomically. So this is near-atomic, not atomic. More importantly, however, is the fact that dpkg won't know anything about this change, so will be unable to detect file conflicts between /usr/bin and /usr/sbin. And we know we definitely *do* have such file conflicts in the archive (see "node-like file conflicts"). Thus we could not guarantee the integrity of the user's system when making such a change. I don't see any gain from merging bin+sbin that justifies such pain. Adding sbin to the default PATH would be far simpler. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature