Sysinstall - why two different programs in 5.3 RELEASE?

Kevin D. Kinsey, DaleCo, S.P. kdk at daleco.biz
Tue Nov 23 10:12:22 PST 2004


Jay O'Brien wrote:

>Why are there two versions of sysinstall, one five times the 
>size of the other, and what are the differences between them 
>other than file size and time?
>
>Jay O'Brien
>Rio Linda, California, USA
>  
>

Sorry I'm late on this ... you've got a good technical
answer already; I thought maybe I could add more
detail; there is, apparently, a more or less historical
reason, as well as the practical one.  The practical
one: it's a Good Thing(tm) to have sysinstall(8) in
/stand/ (on the root partition) where you can get at it
in the event /usr is unavailable.  Indeed, it pretty
much *has* to be under / to install the system....

History wise, sysinstall started out 10 years ago
in /sbin.  Looks as if Poul-Henning-Kamp and either
Bill Paul (or Paul Traina?) did the work.  From the
oldest dusty attic:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/sysinstall/Attic/

Then, for 2.0, Jordan Hubbard "birthed the monster"
that, I guess, is still sysinstall today ... although it's
morphed so many times, it's probably not recognizable
as the same beast any longer[?] {Basically, how could I
know, as a relative newb with Neandertal C skills?}
For a long time afterwards, sysinstall lived in
/usr/src/release:

http://www.freebsd.org/cgi/cvsweb.cgi/src/release/sysinstall/Attic/

Both of these sysinstalls, near as I can tell, built their
binary(ies) into /stand/, but nowhere else.

Now, sysinstall doesn't inhabit "userland", per se.
AFAIK /usr/src/release doesn't get rebuilt during
a "make world" cycle; furthermore, though slightly
less relevant, /stand/ isn't in $PATH --- if you try
"whereis sysinstall" on a 4.X box:

#whereis sysinstall
sysinstall: /usr/share/man/man8/sysinstall.8.gz

Perhaps I'm reading history wrongly, but it seems the
Project wanted to DTRT and make sure that if an
updated manpage was installed for sysinstall, the
updated binary was, also.  To have the manpage
say something the binary can't/won't do violates
the POLA, something the Project is exceptionally
loath to do in almost every situation .... 

So, the bikeshed got painted again: sysinstall
was moved to /usr/sbin, where it would be
rebuilt when the system was updated.  Prior to
that time (Jan. 2001), you had to go to
/usr/src/release/sysinstall and "make all install" to
update the binary under /stand/ --- leading to a
situation where you might have, say, 4.2 installed,
but have a sysinstall binary left over from 3.0 or
something, and it wasn't very useful.  Furthermore,
you can still have a similar situation in 4.X, because
the change was never MFC'd to  -STABLE, and therefore
hasn't appeared until 5.X; (Hmm, will this become a FAQ?)
Note I didn't say "same problem", but "same situation";
I don't personally know if any additional work on
sysinstall during the 4.X's reign as production
release would have rendered an older version
obsolete or not.  I'm tempted to say it hasn't much,
because the "libh" project was supposed to complete
reimplement the installer, and I think the old
monster had been more/less left to hide in his
cave and blow smoke at passers-by (complaining
about the installer *IS* a FAQ)....

You can find the discussion about the change at:

http://docs.freebsd.org/mail/archive/2001/freebsd-current/20010114.freebsd-current.html

The second "sysinstall" thread ("sysinstall.8 breaking buildworld") kind
of shows how it got hashed out amongst the committers, and has some
other factoids that I found educational.  I hope my penchant for historical
digression hasn't annoyed you, and welcome corrections to what I've
presented as facts (though we needn't be pedantic, IMHO)

Kevin Kinsey


More information about the freebsd-questions mailing list