Project

General

Profile

Actions
Copy link

Bug #962

closed

Installer import into HEAD

Added by dave1 almost 17 years ago. Updated over 16 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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.

Actions
Copy link
 #1

Updated by corecode almost 17 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

Actions
Copy link
 #2

Updated by dave1 almost 17 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.

Actions
Copy link
 #3

Updated by dave1 almost 17 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.

Actions
Copy link

Also available in: Atom PDF