Re: [RFC] Rewriting sade(8)

2010/4/9 Dag-Erling Smørgrav <des_at_des.no>:
> Garrett Cooper <yanefbsd_at_gmail.com> writes:
>> Dag-Erling Smørgrav <des_at_des.no> writes:
>> > Garrett Cooper <yanefbsd_at_gmail.com> writes:
>> > > Dag-Erling Smørgrav <des_at_des.no> writes:
>> > > > [restored relevant context which was removed earlier in the thread]
>> > > > ...which is exactly what I said - but in the sysinstall case, you may
>> > > > want to ask some additional questions ("are you sure you want to proceed
>> > > > without a swap partition?") or place some additional constraints (such
>> > > > as "don't allow the user to mount something on top of /mnt or /rescue"),
>> > > > and sysinstall needs to know the outcome.
>> > > If the user shoots him or herself in the foot, that's their own
>> > > problem.
>> > That kind of attitude is why people choose Linux over FreeBSD...
>> Where do you draw the line though? /media, /libexec, /proc, /sys, etc?
>> I think it's better to educate users than build in more complexity to
>> the install application.
>
> I draw the line at mounting something - anything - on top of directories
> that contain files that are critical to sysinstall's operation.  IIRC,
> /mnt is where the installation CD is mounted.

Ok... rather than hardcoding this list into sysinstall or sade, it
would be nice if it was in some kind of flexible metadata.

> In sysinstall mode, sade's role is to 1) make sure that something
> sensible is mounted in the location where sysinstall is going to install
> the OS, 2) assist the user in making the correct disk, slice, partition
> or what-have-you bootable,

What is sensible today, may not be sensible for all cases or sensible
tomorrow. For instance, there have been some reports about the `Auto
defaults' in sysinstall completely screwing up the size as the default
was way too low for /, and thus a user shot himself in the foot when
doing a binary upgrade via freebsd-update. This `smart default' needs
to exist as a minimum and maximum defined in some kind of metadata,
and it would definitely help if one knew what the use-case would be
for the machine, but one doesn't know this data from the way that
things have been setup.

> 3) within reasonable limits, prevent the user
> from doing something that will break sysinstall,

Point being, how do you qualify the act of not `break[ing] sysinstall'?

> and 4) optionally allow
> the user to prepare additional filesystems that sysinstall doesn't care
> about (e.g. /usr/obj), as long as this does not conflict with 3).
>
> I think the easiest way to achieve this is for sysinstall to provide an
> empty directory (e.g. /inst) and have sade operate with that directory
> as root, so what the user sees is how things will look when the system
> reboots after installation; when the user asks sade to create /usr/obj,
> sade actually creates /inst/usr/obj.

Now you're making a dangerous assumption that /inst isn't being used
by the end-user for any predefined purpose.

> Last but not least, sade should report what it did to sysinstall -
> perhaps in fstab format, since sysinstall needs to populate
> (/inst)/etc/fstab anyway.

Ok. Or maybe since `we're here' sade needs to be populating
$DESTDIR/etc/fstab, not sysinstall ? Ideally sysinstall should be a
thin wrapper over a number of different utilities which would provide
the code for thinking things together, not doing a bunch of
operations. That way the code itself could be divorced from the
activities it's performing a bit better and people could swap in other
solutions as they feel fit (say the PCBSD QT installer, or the myriad
of different installers available today for FreeBSD in GTK, QT, etc
format).

Thanks,
-Garrett