Date: Mon, 16 Apr 2007 13:35:08 +0200 From: Dejan Lesjak <dejan.lesjak@ijs.si> To: Kris Kennaway <kris@obsecurity.org> Cc: lesi@freebsd.org, x11@freebsd.org Subject: Re: Upgrade script Message-ID: <200704161335.09045.dejan.lesjak@ijs.si> In-Reply-To: <20070416092629.GA36962@xor.obsecurity.org> References: <20070414194028.GB2313@xor.obsecurity.org> <20070416005331.GA33243@xor.obsecurity.org> <20070416092629.GA36962@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > 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. > 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. > 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. > 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. xorg-libraries is just the metaport by which they should depend on all these new sub-ports. In time the ports that depend on xorg-libraries can convert this dependency to specify exactly which of these modular packages they actually depend upon. > 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. Exactly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704161335.09045.dejan.lesjak>