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.
| 1. Move rc.d/{xdm,xfs} to xetc.tgz
| 2. Let the build descend into etc/rc.d for obj and dependall
| 3. Introduce FILESBUILD_<file> as discussed on tech-userlevel
| 4. Use it to build the xdm and xfs rc.d scripts
| 5. Sprinkle /usr/X11R7 into all the relevant profile/cshrc/whatever,
| giving it priority over /usr/X11R6.
These all seem non-contentious.
I would do 3 first, as a separate commit.
| 6. Change postinstall(8) so that it is generated at build time to
| get the value of X11ROOTDIR hard-coded.
I don't like this; I'll address below.
| 7. Change postinstall(8) so that it is able to generate xdm and xfs
| when run with a source directory as input.
I'm not sure about how you've implemented 6 and 7; I'll address below.
| The issue I have with 1 is how to deal with non-x11 (either flavour)
| update builds; build.sh will find extra files in DESTDIR. I'm not
| sure if they can be "obsoleted" in any way though.
Don't attempt to solve the problem; just document that MKUPDATE!=no
builds without MKX11/MKXORG may need to manually tweak their
DESTDIRs.
| Arguably, we could generate all the files touched for 5. It's more
| work, but would allow use to have clean files for non-x11 builds.
I don't think this is necessary.
| The wacky way I do 6 is only so that the source file is not renamed, so
| that CVS history is not lost. I'm fine with renaming it postinstall.in
| and doing the transformation in a more traditional way.
As Alan said, .in is more consistent. But I'm not sure we
need to generate postinstall. (See below)
| 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?)
| 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.
* 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?
* The other X11R6/X11R7 changes in postinstall are not necessary.
| 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 ?
| 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.
| Index: usr.sbin/postinstall/postinstall
| @@ -1235,7 +1255,7 @@
| obsolete_libs /lib
| obsolete_libs /usr/lib
| obsolete_libs /usr/lib/i18n
| - obsolete_libs /usr/X11R6/lib
| + obsolete_libs @X11ROOTDIR@/lib
| ) | obsolete_paths "${op}"
| failed=$(( ${failed} + $? ))
This particular part shouldn't be needed; just add both X11R6 and
X11R7 to the paths to attempt to obsolete.
In summary;
* FILESBUILD_ looks ok
* Moving rc.d/x* to xetc.tgz looks ok
* The postinstall stuff needs a rethink, and most likely doesn't need to
be generated with hard-coded X11ROOTDIR paths.
cheers,
Luke.
Attachment:
pgp1TFMZ5cI4X.pgp
Description: PGP signature