[RFC] Rewriting sade(8)
rpaulo at freebsd.org
Thu Apr 8 14:08:42 UTC 2010
On 8 Apr 2010, at 13:49, John Baldwin wrote:
> On Thursday 08 April 2010 5:05:34 am Dag-Erling Smørgrav wrote:
>> Alexander Leidinger <Alexander at Leidinger.net> writes:
>>> Please consider using SVN instead. A lot more users will be able to
>>> check out from there.
>> We don't grant non-committers access to the Subversion repo.
>>> It looks like other people had a look at sysinstall, not at sade. As
>>> sysinstall is supposed to be used at installation time, and the intent
>>> for sade was to offer the functionality (or more) of the part of
>>> sysinstall which is useful after installation (and to prevent admins
>>> from using sysinstall after the installation to prevent some unwanted
>>> foot-shooting), I do not think that we need to think about a strong
>>> lock between sysinstall and sade.
>> Yes we do. Otherwise we'll just end up back where we are today, where
>> if you want anything more complicated than a single-disk install you
>> have to drop into the fixit shell and do it manually before running the
>> installation procedure. Anythig that sade can do, we want sysinstall to
>> do as well, and we don't want to implement everything twice.
>> My suggestion is to add a "sysinstall mode" to sade where it operates
>> under certain (minor) constraints and reports what it did in a format
>> that sysinstall can parse, so sysinstall can just fork-exec sade instead
>> of duplicating the code.
> Actually, I would rather have sysinstall just invoke sade to do the disk
> related stuff. Also, I think sysinstall should allow for a "back-door" mode
> where a user can setup partitions however they like and mount them at /mnt and
> then let sysinstall use the setup the user created. This will allow users to
> setup more complex setups that sysinstall/sade do not currently support and
> allow sade to focus on simpler, common usage cases w/o having to handle
> painful edge cases. It would also allow for new modules to be added to sade
> over time w/o requiring it to support every possible disk layout from the
I couldn't agree more.
More information about the freebsd-current