The strangeness called `sbin'

[Ed Schouten]

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 at 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,
-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20111114/c8c40d91/attachment-0001.pgp