From owner-freebsd-x11@FreeBSD.ORG Mon Apr 16 19:08:14 2007 Return-Path: X-Original-To: x11@freebsd.org Delivered-To: freebsd-x11@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EF6016A400; Mon, 16 Apr 2007 19:08:14 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7829213C45B; Mon, 16 Apr 2007 19:08:14 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 8CEA91A4D82; Mon, 16 Apr 2007 12:08:27 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8CD67513AD; Mon, 16 Apr 2007 15:08:13 -0400 (EDT) Date: Mon, 16 Apr 2007 15:08:13 -0400 From: Kris Kennaway To: Dejan Lesjak Message-ID: <20070416190813.GA65729@xor.obsecurity.org> References: <20070414194028.GB2313@xor.obsecurity.org> <20070416005331.GA33243@xor.obsecurity.org> <20070416092629.GA36962@xor.obsecurity.org> <200704161335.09045.dejan.lesjak@ijs.si> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <200704161335.09045.dejan.lesjak@ijs.si> User-Agent: Mutt/1.4.2.2i Cc: lesi@freebsd.org, x11@freebsd.org, Kris Kennaway Subject: Re: Upgrade script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 19:08:14 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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) >=20 > Hmm. It should help in this case if xorg-libraries are upgraded first, th= en=20 > xorg-clients/xorg-apps and only then the rest. Do you happen to remember = why=20 > 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. >=20 > This will probably do better, yes. The instruction to first run script an= d=20 > then upgrade was pretty much arbitrary; I didn't see much difference in o= rder=20 > 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? >=20 > 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. >=20 > It might cause problems in users configurations and probably some ports t= hat=20 > expect things in /usr/X11R6 that will now be in /usr/local, but one can= =20 > always "fix" this by making symlink at such time, so it shouldn't really = be a=20 > 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 --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGI8mdWry0BWjoQKURAtHGAKCV7uKggRurchKkzdf73DEHtklYdQCZAbRd hJhIlsTQddx3jl2WRMBXESA= =Kjcj -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW--