Date: Mon, 14 Nov 2011 20:34:34 +0100 From: Ed Schouten <ed@80386.nl> To: Robert Watson <rwatson@freebsd.org> Cc: Tim Kientzle <tim@kientzle.com>, Doug Barton <dougb@freebsd.org>, mike@karels.net, arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: The strangeness called `sbin' Message-ID: <20111114193434.GC2164@hoeg.nl> In-Reply-To: <alpine.BSF.2.00.1111141745001.94325@fledge.watson.org> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <alpine.BSF.2.00.1111141745001.94325@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0uCeA/GhJk5vQd80 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Robert, others, Before I get to the subject, please excuse me for not commenting on all your emails individually. I am afraid that if I would do that, the discussion will fragment. The first thing I noticed is that some of the emails mention that the work I proposed was a solution searching for a problem. I have to emphasize this is clearly not my intention. It was something that I started to notice when I was working on the utmpx code in 2009, where half of the utilities were stored in /usr/bin, while the others were placed in /usr/sbin. The reason why I let it wait until now, is because even though I was considering moving the tools around back then, I realized that this causes major headaches for our users, because if they don't run `make delete-old' (which isn't even described in the handbook, by the way), they'll end up having two copies. I reasoned that performing a merge of sbin to bin automatically fixes this. Combined with the arguments that I gave in my opening email, I am under the impression that this is something that we should consider. The reason why I brought it up last week, is because I got reminded of the issue by seeing the Fedora discussion. So to summarize: the reason why I proposed this, is _not_ because the Fedora folks think it's cool, it's because work in this area was (is?) on my TODO list anyway. The fact that the Fedora folks are also discussing this, was only a confirmation for me that this is a point of discussion in a larger part of UNIX-land -- not just FreeBSD. Now let me respond to Robert's email specifically, as it raises an interesting point, which I already thought about, but had not specifically mentioned in the introduction email. =46rom now on, let us assume we're discussing the patchset I have sent to the list initially -- not the discussion between Doug and I, where we discussed a full merge into /bin and /lib. * Robert Watson <rwatson@FreeBSD.org>, 20111114 18:48: > Ditto. I agree with Ed that it is more aesthetically pleasing and in > keeping with the actual design principles we have, but it would be > quite disruptive for downstream users. Especially if the source tree > is rearranged, since not all revision control systems (or import > methods) take kindly to large-scale renaming of subtrees with > substantial patches. <snip> So let us divide our users in two groups; regular users and vendors. Group 1: regular users ---------------------- In my opinion the patch isn't really disruptive for our end users. One of the things that I don't want to do, is perform the merge of the sbin and games directories automatically. This is because one small error or assumption in our scripts can render many the system unbootable. If it turns out we don't have anything to worry about, we could eventually automate this through some means. If committed to SVN in its current form, users will experience the following upgrade procedure: - csup or svn up the source tree - The user compiles the source, installs the kernel, reboots, etc. - The user runs `make installworld', but it will simply print a message, asking the user to read /usr/src/UPDATING, which contains four simple shell commands that perform the merge. - When done, the user runs `make installworld', which will now continue to work properly. So all in all this is a pretty simple procedure. The total overhead is only four small shell commands on a single `make installworld'. Compared to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say the least. Group 2: vendors ---------------- So a pretty serious point that Robert raises, is that changes to source tree layout are really irritating for our vendors. Now keep in mind that I have mentioned nothing in particular about source tree layout. Even though it would be a lot more consistent if those directories are merged as well, I have not been promoting this. We could easily put the following policy in place: any new (or massively rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories are left the way they are. In other words: the directory src/usr.sbin/ can be described as "applications that were historically installed in /usr/sbin". So vendors shouldn't notice that much of the transition. They can just build on top of our source tree the way they currently do. The only merge conflicts they could experience, are lines of code where we replace path names, but conflicts in that area are as likely as any other changeset. I think this message covers most of the things I wanted to say for now. I really hope we can continue this discussion in a fruitful manner. I have noticed that even though there has been criticism, there have also been many people that have expressed support for this work, both privately and on the mailing list, so it would be nice if this discussion actually leads to something useful. Just because certain aspects have so far not been worked out completely, doesn't mean the idea as a whole is a bad thing. And if it turns out to be a bad thing, then so be it. At least it has served as a lesson. Maybe it's worth asking yourself this question: "say, we were to merge sbin with bin, what kind of problems can we walk into and how should they be resolved?" Thanks, --=20 Ed Schouten <ed@80386.nl> WWW: http://80386.nl/ --0uCeA/GhJk5vQd80 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOwW1KAAoJEG5e2P40kaK7ZQQP/3qfaUBCjj6GAhnzOuWaL73o Iq6FeWdbqCbG7H8LtSaktTjhD+RQCFwkPuZO2uvIJAep24JsS08p1UgN6MOlBLRA 9tVZgp4UM7iVXH4hUomeCHZGUKx+JnMvTQ/9KAxL8+crN7iyoXoDT0OXP9ruE5Sf 0MkbsPJNhF5Tzxqo9Tuia+ITgWbhbVwCA0UebGCy8k23r1tGzBWkhn+uLe0Az+aw sAPF5bfw+ztQ30qaAJCqlW0FGjVog7Iix9CJn5QUBtcl+7Ilyj43uoAmkJygdDfn VzYjzOC9xRlrmLBYGt10mb1NYP0hHUcAKgmVhZuboH7bMga5hZAMpF7MpfOz/w5X DTfc4348utcPgHgY0uUw5Odt0y8YERtaF+JLYN0dxfMT+2OGPr2ENK4bdTkN11ap CgaeDcaXRsN0chHULfNTkdHxPyYrz9Zz/Ra91Rs/kAzn3mXl2USM5196769GM4V5 BuQGuuVykNhZDUh6koMD5GkC7zotKx/DPcghm2B/GaZxKIG2MBQfnId0r/Lw+Fv3 AAGlYB7c83MftgqfB9ERHQXeguh9cD/hngThsdTzckEEP5h7j3teyQPWZfL3tzn5 gGpykO+FcYLtKQCe9IVE6ayLXaAE6ZwvOH1EXGciB7BwLawM2TfvLQ7JGCd91iby xFxvLoFWGMKW27LCJaDP =n+uK -----END PGP SIGNATURE----- --0uCeA/GhJk5vQd80--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111114193434.GC2164>