Date: Wed, 23 Apr 2014 11:13:46 -0700 From: <dteske@FreeBSD.org> To: "'Randi Harper'" <randi@freebsd.org>, "'Allen Landsidel'" <landsidel.allen@gmail.com> Cc: freebsd-sysinstall@freebsd.org Subject: RE: bin/164281: bsdinstall(8): please allow sysinstall as installer option Message-ID: <012501cf5f1f$c5e7c740$51b755c0$@FreeBSD.org> In-Reply-To: <CAM9wqY8Bn9yQvMbpMdg1wcVhx5AGgK6rP1tkh9qccDhWZaU9Kw@mail.gmail.com> References: <201404151630.s3FGU0Zg026166@freefall.freebsd.org> <CAM9wqY8Bn9yQvMbpMdg1wcVhx5AGgK6rP1tkh9qccDhWZaU9Kw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message-----
> From: Randi Harper [mailto:randi@freebsd.org]
> Sent: Thursday, April 17, 2014 2:33 PM
> To: Allen Landsidel
> Cc: freebsd-sysinstall@freebsd.org
> Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as
installer
> option
>
> YOU HAVE MY AXE.
>
> -- randi
>
>
> On Tue, Apr 15, 2014 at 9:30 AM, Allen Landsidel
> <landsidel.allen@gmail.com>wrote:
>
> > The following reply was made to PR bin/164281; it has been noted by
> GNATS.
> >
> > From: Allen Landsidel <landsidel.allen@gmail.com>
> > To: bug-followup@FreeBSD.org, cederom@tlen.pl,
> > devin.teske@fisglobal.com
> > Cc:
> > Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as
> > installer option
> > Date: Tue, 15 Apr 2014 12:22:52 -0400
> >
> > Any movement on your project, Devin?
> >
> > Many of us that have been using FreeBSD for years ('96 here) would
> > love to see sysinstall return. Whatever sysinstall's failings,
> > bsdinstall is far, far worse.
Making bsdinstall better than sysinstall is possible. Making sysinstall
better than bsdinstall is possible (if revived to some branch where it
won't be insta-nuked).
The issues with reviving sysinstall are as follows with commentary:
1. To run sysinstall, it has to be ported to new libdialog
Ok, so that's not hard. That's trivial in-fact. Just a lot of mundane
repetitive analysis of each invocation of each widget and changing
the arguments to match the new API. Maybe occasionally modifying
the code to call some more-appropriate widget that may be smarter
than the limited selection of widgets provided by the old libdialog.
2. sysinstall doesn't support GEOM
There's good news here. I'm just finishing up code on bsdconfig
(which *cough* is modeled after sysinstall) to not only add GEOM
support but drop all legacy methods of device inquiry (GEOM is the
sole basis for device scanning; aside from ifconfig to get get the
network interfaces which are not represented by GEOM).
Since the bsdconfig sh(1) code is literally converted C code from
legacy sysinstall(1), that opens the door for a reverse migration to
teach sysinstall about GEOM (read: bsdconfig's sh(1) code simulates
structs, arrays, and sundry so converting back to C code is trivial).
===
So recap of what it looks like...
sysinstall was forced into deprecation because of a new libdailog
and a need to migrate to GEOM. Nobody solved those things so it
was ultimately axed and we started over.
After years of toiling in a silo, I'm adding those things (but so much
more), and I can see in retrospect that those things were not trivial.
But here's the question...
As I continue the lay the ground-work for a bsdinstall that is superior
to sysinstall, do I split my time amongst that task and provision a new
task of migrating sysinstall toward resurrection with the afore-
mentioned fixes?
That's a hard question to ask. I still have many thousands of lines of
uncommitted code to work toward the end of making bsdinstall
better than sysinstall, and bringing those uncommitted lines to the
point of commit is still more work. Partitioning the time I spend on
that megalithic load to resurrect sysinstall steals time from making
it across the finish-line without legacy tools (old libdialog and old
device probing that doesn't recognize GEOM).
So to help answer the question of prioritization (given that demand
still exists for sysinstall), I think the best way to guide us is a Wiki.
I recommend that we develop a f.o Wiki that we can all edit to
contain our partiticular misgiving of bsdinstall versus sysinstall.
I have quite a few in-mind and they guide my work on both bsdconfig
and bsdinstall (a note to those that don't understand the relationship
between the two: bsdconfig receives functionality first and then later
bsdinstall inherits from bsdconfig -- example: zfsboot which uses the
bsdconfig API heavily). I suspect others that have taken the time to
run bsdinstall that still want sysinstall will have many more nits to add
to such a Wiki.
The Wiki can tell me which things in bsdinstall need focus so I can
focus on things that are "more broken" than others. While at the same
time, I can see how much further we have to go until we can say that
sysinstall is no longer needed by any workflow.
That being said... with respect to the actual PR of bringing back sysinstall
as an option... I'm not against it. In fact, seeing that someone posted on
the PR to check-up on me, I think it's time (once 9.3 comes out) to roll a
new Druid disk. For those that don't know... I serve sysinstall based media
from druidbsd.sf.net for 9.x releases (albeit I haven't cut one since 9.0).
I'll make sure to cut one for 9.3 so that people wanting sysinstall can not
only have it, but can have the one I developed for $work which has many
MANY enhancements -- *cough* including the ability to install from a USB
thumb drive *cough*. (smiles)
--
Devin
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?012501cf5f1f$c5e7c740$51b755c0$>