> Our autolabel sizes seem mostly based around desktop-type machines (though > /usr/local is a bit too small these days, /usr/X11R6 acceptable but seems > stingy, and there are probably equal numbers of those who would quite > like to have /usr/ports and those who really wouldn't want to waste the > space). >
I do not agree with those assessments. > And I think that is who we optimised for. People who don't know what they > want can hit enter, people who do go through disklabel(8). In that case, what's the fuss? > That doesn't carry across to "everyone hits enter" for autoinstall. autoinstall is a definately a lower-class citizen in this regard. The proposed hacks to support fdisk/disklabel this are deeply invasive and will harm maintainablity of the install scripts. I believe maintainability for the generic case is more useful, and I continue to believe that the usage cases these hacks are written by scrimpers. > for many of the sorts of machine where autoinstall would be useful, the > current /usr/local size is reasonable, /home is way too big, and 4GB max > in alloc_big[] for /var on a "server" just seems dangerous. Well.... then you and others should be proposing step-by-step tweaks and improvements to the heuristics, rather than asking for incredibly complex direct configuration, or more buttons which people won't select because the effects are not easily described. (I will continue my mission against complex semantics which are described in some corner of some monster FAQ...) > So what else could we do? Separate "server"/"client" tables? Even just > swapping the standard sizes of /home and /var for an autoinstall would make > it a lot more useful. I disagree on all those points.
