Upgrade script

[Kris Kennaway]

On Sun, Apr 15, 2007 at 08:53:31PM -0400, Kris Kennaway wrote:
> On Sat, Apr 14, 2007 at 10:13:00PM -0400, Kris Kennaway wrote:
> 
> > > > I confirmed this on an attempted 
> > > > upgrade of an xorg 6.9 machine.
> > > 
> > > What was missing from 7.2?
> > 
> > libXau failed, followed by:
> 
> OK, this is repeatable.  What is happening is that when I kick off
> portupgrade -a, xproto builds early and updates some headers (spamming
> over the top of xorg 6.9 files), then some time later xorg-libraries
> builds, and when it deinstalls the old 6.9 port it deletes the headers
> installed by xproto.  Then things like libXau fail to build.
> 
> It still looks to me like removing all of the old xorg ports first is
> the only way to avoid this kind of problem; this problem is general
> and will probably affect other of the xorg-foo metaports too (i.e. the
> files they used to own have also migrated into subports, so the same
> thing will happen: the subports are installed first and spam some of
> the xorg 6.9 files that are still present, then the metaport builds,
> deinstalls the old 6.9 version, and deletes those files leaving
> nothing behind)

OK, after several sleepless hours worrying about how much the xorg
upgrade is going to suck for our users, I think I might have thought
of a better way.

Instead of running the mergebase.sh script before the xorg upgrade,
run it after the upgrade.  This will avoid the above problem of files
moving against the natural order of the dependency tree, because the
xorg 6.9 files are all in /usr/X11R6, and the new ones are installed
into /usr/local so nothing is being overwritten.

Apart from the xorg-manpages special casing in mergebase.sh, this
should even allow portupgrade -a to work correctly.  I am not sure why
xorg-manpages needs to be special-cased; it looks like the manpages
are migrating into xorg-docs, so can't we use a MOVED entry to do that?

Running mergebase as a post-install script also has the advantage that
if someone forgets, it may not be a fatal problem: most ports are
X11BASE-clean, so if /usr/X11R6 hangs around on their system they may
not even notice.

Another possible issue with the upgrade is that if we only bump
portrevision on ports that used to live in X11BASE, and not the
LOCALBASE ports that also depend on X (KDE, GNOME, etc), the latter
will not get a full set of updated dependencies (i.e. they will only
be recorded as depending on xorg-libraries-7.2, when they should also
be depending on all of the new xorg sub-ports too, e.g. libXfoo,
lameproto, etc).  pkgdb -L will fix this for portupgrade users, but
not for others.

However, it might actually not be an issue, since there is still an
implied linkage via xorg-libraries (and similarly for the other
metaports).  i.e. when someone does a portupgrade -R kde or similar,
it will recurse to xorg-libraries and then to all the xorg subports
and upgrade any that are out of date, even if there is no direct
dependency on the subports recorded.

Kris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20070416/2aaa3d7b/attachment.pgp