Upgrade script

[Kris Kennaway]

On Mon, Apr 16, 2007 at 01:35:08PM +0200, Dejan Lesjak wrote:
> On Monday 16 of April 2007, Kris Kennaway wrote:
> > 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)
> 
> Hmm. It should help in this case if xorg-libraries are upgraded first, then 
> xorg-clients/xorg-apps and only then the rest. Do you happen to remember why 
> xproto got built before xorg-libraries?

It is allowed, because xproto does not depend on anything.
xorg-libraries depends on the new ports, so according to the usual
rules xorg-libraries *must* be built after those ports have been
built.

 It is a big violation of the "natural order of things" for files to
migrate from living in one port to living in a dependency of that port
(for this reason), and we don't have a way to deal with this apart
from the "delete everything first, then patch it back up" radical
surgery approach I was previously afraid we'd have to resort to.

> > 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.
> 
> This will probably do better, yes. The instruction to first run script and 
> then upgrade was pretty much arbitrary; I didn't see much difference in order 
> but now it does seem that it would be better to run it after.

OK, cool.  I will try the upgrade again with the below modification
when I have the chance.

> > 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?
> 
> Some of them are migrating to separate lib* ports.

OK, but to a first approximation we can use xorg-docs?

> > 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.
> 
> It might cause problems in users configurations and probably some ports that 
> expect things in /usr/X11R6 that will now be in /usr/local, but one can 
> always "fix" this by making symlink at such time, so it shouldn't really be a 
> problem.

Yes.  The real fix is for such a person to run the mergebase script
anyway, but it shouldn't leave them with a completely nonfunctioning
system if they forget at first.

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/9ece8678/attachment.pgp