Date: Mon, 14 Nov 2011 13:45:03 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Ed Schouten <ed@80386.nl> Cc: Tim Kientzle <tim@kientzle.com>, Doug Barton <dougb@freebsd.org>, mike@karels.net, arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: The strangeness called `sbin' Message-ID: <CAGH67wRj2iE4kGMmSU1z_8-ixeBBUMtJ5L8CWmYyePNH4yiR3A@mail.gmail.com> In-Reply-To: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <alpine.BSF.2.00.1111141745001.94325@fledge.watson.org> <20111114193434.GC2164@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 14, 2011 at 11:34 AM, Ed Schouten <ed@80386.nl> wrote: > 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. > > From 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. =A0I 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. =A0Especially 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. =A0<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, > =A0asking the user to read /usr/src/UPDATING, which contains four simple > =A0shell commands that perform the merge. > - When done, the user runs `make installworld', which will now continue > =A0to 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?" Having written a few shell scripts and debugging others' -- I can speak from experience and say that there are folks who do one of the following: 1. Hardcode paths to utilities (/usr/sbin/sysctl comes to mind). Maybe for optimization; maybe to avoid alias'ing, etc. 2. Use which / command -p / etc to divine where their binaries come from. 3. Hardcode PATH to a restricted path to ensure determinism. 4. Just dash it all and call commands without any predivined path. 5. People might have come up with tricky ways of determining real files from symlinks in their scripts or other programs in order to 'divine' their existence. 6. People have come up with interesting path overlaying; this is especially true in larger companies where there's 15+ years of development history, e.g. my previous employer. The difference between one binary and another is the difference between your application working and not working. Please be careful because I'm sure your changes are going to break items 1., 2., 5. and 6., which is going to break a lot of 3rd party scripts, binaries (vendor code like the mergepoint BMC update utilities), ports, and packages in inexplicable ways. Anyhow, back to your regularly scheduled bikeshed. Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wRj2iE4kGMmSU1z_8-ixeBBUMtJ5L8CWmYyePNH4yiR3A>