On Wed, Oct 29, 2008 at 10:29:10AM +1100, Luke Mewburn wrote: > On Tue, Oct 28, 2008 at 08:55:26PM +0100, Quentin Garnier wrote: > | The attached patch does the following: > > I suggest splitting up the patch into separate work items, > so the non-contentious stuff can be committed without waiting > for the other stuff to be finalized. Oh, I agree. It wasn't my intent to commit all at once anyway, but I consider it one patch because it's all about X.Org vs. XFree86 and /etc. [...] > | Now, as for the debate that will surely arise as to whether or not > | postinstall(8) should have embedded information, I'll say that > | postinstall ships with the base system, in base.tgz, so it has to > | match said base system, so generating it is ok. > > Except that X11 system may be installed separately (after) the base > system, or may even be changed. > (Or does the selection of MKX11 vs MKXORG change the base build?) Well, there is the issue of sshd and ssh invoking xauth. > | I don't think 7 is too perverted, and could probably be used for other > | things in the future. > > We'd need to be pretty careful about this; postinstall currently > doesn't invoke make(1), even for source postinstall. > It's starting to get into the terrority of etcupdate(8). > > There appears to only be one place that postinstall currently > needs the X11ROOTDIR: do_x11(). > > * For "postinstall from sets", we could detect the /usr/X11R6 > or /usr/X11R7 and change the behaviour of do_x11() as necessary. postinstall from sets is not an issue because the files in the sets are already properly generated. > * For "postinstall from $SOURCE", we'd need to do some smarts > about invoking make(1) and determine the build settings > of MKX11 and MKXORG. Doesn't etcupdate(8) have some useful > and robust code for that? That code is not that robust. We have to make sure all the variables are passed down to the make which is invoked. And in the typical run of build.sh install=/, you're told to run postinstall in a certain way; if you had -V arguments to build.sh, they need to be passed down there too. > * The other X11R6/X11R7 changes in postinstall are not necessary. Ok. The less changes the better. > | Now a bit of generalisation. I realise that /usr/X11R7 might not have > | been such a good idea after all. I'm still opposed to /usr/X11R6, and > | still don't think /usr is workable. (And I don't think I opposed > | /usr/X11 If I recall correctly.) OTOH, moving XFree86 to /usr/X11 is > | not a trivial task either, and using /usr/X11R7 or /usr/X11 for X.Org > | matters little if XFree86 is not moved to the same base directory > | altoether. > > Are there any lessons we can learn from other systems here? > Including historical stuff such as the upgrade from X11R5 -> X11R6 ? I don't know. But I don't think we'll find anything recent anyway. > | Comments? I'm aware I still have to deal with the path to xauth > | embedded in ssh, but I'll look at it later. Also, I'm not used to > | hacking postinstall, there might be better ways to do what I make it do > | and I'll be fine with any cosmetics remarks for that part of the patch. > > The core idea that I intended for postinstall is ``don't fubar the system''. > It's intended to automate configuration upgrades in sync with base system > upgrades so that the user doesn't end up with a hosed system. > Sometimes changes to postinstall have broken that underlying promise, > and that's when I get cranky :) > That said, I don't think that fubaring the system is your intention. I don't think it was the intent of all who broke postinstall either :-) I'll have a look at doing it the etcupdate way, but I'm not convinced the hard-coded way is really worse. There's a thrid option: using /usr/X11 everywhere and providing a symlink to either X11R7 or X11R6 depending on the settings. That would remove the need for most of my original patch. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgp7aVKLK4XEz.pgp
Description: PGP signature