[RFC] Rewriting sade(8)

[Rui Paulo]

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 
> beginning.

I couldn't agree more.

Regards,
--
Rui Paulo