Mirko Thiesen wrote:

> I think you are indeed wrong here - sysinst is perfectly doing what it 
> is designed for: installing a base NetBSD system which is actually working.

Okay. And a good thing for it to do. Doesn't mean it has to be so narrow 
minded about it.

> Huh? The situation is as follows: sysinst is behaving in some way, and 
> someone suggested to change this behaviour. Wouldn't it be their turn to 
> provide a reason why sysinst's behaviour should be changed in the first 
> place?

As I have come to understand sysinsts behavior inexplicably changed and 
people complained, only to be told to bugger off. That's not right IMHO. 
In that case I believe it to be the job of whomever made the change to 
explain why they chose to make this pain in the tail to others change.

> Pardon? Until now there was no real reason given for the need of 
> overlapping partitions. In fact, the only explanation given by the 
> people demanding a knob to override the disklabel check was that they 
> had used overlapping partitions in the past and would like to be able to 
> create disklabels with overlapping partitions from within sysinst in the 
> future.

I've seen data migration and different uses for the same chunk of space 
at different times given - i've done the 2nd in a Linux/windows dual 
boot - same disk area was used as swap space for both platforms 'cause 
neither really cared and happily wiped it when they came up, and I 
needed swap space for both but not at the same time. Or did I just 
imagine those being mentioned?

> Sorry, but I really think you are misguided here. IMHO, an "over 
> sensitive disk sanity check" would be one which prevents you from doing 
> something important and/or useful - something that would at least WORK. 
> Overlapping partitions don't belong to this category. Just by the fact 
> that the kernel doesn't panic when it reads a disklabel containing 
> overlapping partitions, such a disklabel doesn't become correct. If you 
> call such sanity checks "over sensitive", then you are wrong - IMHO.

Obviously it's useful to someone or this change wouldn't have gotten 
complained about. :) And it is over sensitive from where I stand - the 
point of the check is to make sure it'll work as configured after 
sysinst is complete, yes? Then all it should care about is that the 
partitions configured to mount _at boot time_, after sysinst is done, 
don't overlap. Mounting of overlapping partitions is obviously an 
expert/idiot thing (depending on who is doing the deciding), and should 
be warned over but not be a critical error unless they would be mounted 
simultainously at next boot. The only way it should always be a critical 
is if sysinst makes an invalid assumption - we will mount all partitions 
somewhere at next boot. If sysinst must make this assumption for some 
reason then that should be given for why it's behavior was changed.

> Of course this doesn't mean that there couldn't be some kind of expert 
> knob or whatever you like to call it in sysinst letting you bypass one 
> sanity check here and another otherwise automated step there. But the 
> main purpose of sysinst is to get a NetBSD distribution from an 
> installation media onto an installation target - working. This is what 
> sysinst is designed for.

All i'm saying is the removal of flexibility there is misguided from 
where I stand. It presumes that one specific way of doing things will 
work and is best all the time, which is terribly misguided IMHO. There 
should always be a means of working around an otherwise automated step 
or non-crucial sanity check here and there, then allowing the automated 
steps to continue. Crucial sanity checks should be limited to truly 
crucial things - i.e. the disklabel crucial sanity test should be the 
same everywhere, if the kernel would find it sane then it's sane but we 
should warn people that mounting partitions that overlap could be 
dangerous and it's not our fault if their boss strangles them for 
screwing up.

--Gerald