Bug #962

Installer import into HEAD

Added by dave1 almost 7 years ago. Updated over 6 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I've got an incoming import of the BSD installer v1.1.6 to /usr/src
which I wanted to get some basic feedback on before I import it (or I
could just import it since it shouldn't muck with anything else
important). To actually use this there are very slight changes to files
under

/usr/src/nrelease/installer

that need to be made.

What I've added are the following directories:

/usr/src/contrib/bsdinstaller-1.1.6
/usr/src/usr.sbin/dfiube_installer
/usr/src/usr.sbin/dfiube_curses
/usr/src/lib/libaura
/usr/src/lib/libdfui
/usr/src/lib/libinstaller

This work puts two binaries in /usr/sbin:

dfiube_installer
dfiube_curses

and does NOT install those three libraries which are only needed
for the installer.

An open question is how to restrict this build to a /usr/src/nrelease
build. I don't know how to do this yet, and I'm not sure it's worth
it.

This was a lot easier than I thought it would be, so naturally
I'm suspicious of it. It does build successfully on my machine
outside of a buildworld (the buildworld test is running now).
--
Dave Hayes - Consultant - Altadena CA, USA -
>>> The opinions expressed above are entirely my own <<<

A king who feared wasps once decreed that they would be
abolished.

As it happened, they did him no harm. But he was eventually
stung to death by scorpions.

History

#1 Updated by corecode almost 7 years ago

This indicates that we don't want to change a lot in the installer? Fair
enough.

I wouldn't scatter everything around in the source tree. All the
libraries are only used by the installer, for instance. Maybe resurrect
/stand? :)

suggest $DIR/libaura, $DIR/lib..., $DIR/frontend/curses,
$DIR/backend/installer

Of course we should move to an installer written in a scripted language,
but that's not on the agenda for now :)

cheers
simon

#2 Updated by dave1 almost 7 years ago

Well, it's more of "the installer we use should be built by our build
system". Also I'm supporting this for myself at the moment, I found a
bug somewhere back there in the time stream, and it would be nice to
commit a bug fix.

I thought about that. My intent was to follow the pattern that sendmail
(and other contrib) currently has in the source tree.

Personally I care not where they actually go, and I do care that I don't
create some off the wall structure that doesn't go against or orthogonal
to the logic that the current structure has.

Can I use BSD.subdir.mk and just move these guys into a subdirectory
without changing the above Makefiles (modulo pathnames with ..)?

I'd love to work on this someday too. However, I doubt we can get a
consensus on which language to use. ;)
--
Dave Hayes - Consultant - Altadena CA, USA -
>>> The opinions expressed above are entirely my own <<<

One of the most common defenses against really learning something is
to believe that one knows it already.

#3 Updated by dave1 almost 7 years ago

Too much reversability thinking here. This sentence should read:

"Personally I care not where they actually go, and I do care that I don't
create some off the wall structure that goes against or orthogonal
to the logic that the current structure has."

Mea culpa.
--
Dave Hayes - Consultant - Altadena CA, USA -
>>> The opinions expressed above are entirely my own <<<

None should say "I can trust" or "I cannot trust" until they
are the master of the option of trusting or not trusting.

Also available in: Atom PDF