From owner-freebsd-doc Wed Oct 16 23: 5:38 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 236CB37B401 for ; Wed, 16 Oct 2002 23:05:36 -0700 (PDT) Received: from south.nanolink.com (south.nanolink.com [217.75.134.10]) by mx1.FreeBSD.org (Postfix) with SMTP id ABA3843E91 for ; Wed, 16 Oct 2002 23:05:34 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 31843 invoked by uid 85); 17 Oct 2002 06:14:28 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by south.nanolink.com with SMTP; 17 Oct 2002 06:14:26 -0000 Received: (qmail 42166 invoked by uid 1000); 17 Oct 2002 06:05:18 -0000 Date: Thu, 17 Oct 2002 09:05:18 +0300 From: Peter Pentchev To: "Gary W. Swearingen" Cc: freebsd-doc@freebsd.org Subject: Re: Curious doc/en*/Makefile Checkout/Delete cycling by cvsup Message-ID: <20021017060518.GB371@straylight.oblivion.bg> Mail-Followup-To: "Gary W. Swearingen" , freebsd-doc@freebsd.org References: <4zlm4z74c7.m4z@localhost.localdomain> <20021016070026.GU372@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-Virus-Scanned: by Nik's Monitoring Daemon (AMaViS perl-11d ) Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2002 at 11:03:27AM -0700, Gary W. Swearingen wrote: > Peter Pentchev writes: >=20 > > The doc build needs the www/links1 port; the 'dump' option support was > > not really merged into links 2.x. >=20 > So is there a bug in www/docproj/Makefile or "portupgrade", or is this > just something that one is expected to manage by hand? >=20 > From www/docproj/Makefile: >=20 > RUN_DEPENDS=3D instant:${PORTSDIR}/textproc/sgmlformat \ > ... > ${PREFIX}/bin/links:${PORTSDIR}/www/links1 \ >=20 > But from "portupgrade -nR docproj": >=20 > - www/links (links-2.0_1,1) >=20 > (and it says nothing about www/links1). No, there is no bug; at the time the docproj port was installed, the dependency line read ${PREFIX}/bin/links:${PORTSDIR}/www/links, pointing at the "real" links port, the only one that was available at the time. Thus, the installed docproj package lists www/links as a dependency, and portupgrade is happy. Whenever some of docproj's dependencies change, portupgrade will try to see if all its dependencies are up-to-date, since it is rebuilding it anyway. The new dependency line still lists ${PREFIX}/bin/links as the file to check, so it will be satisfied by the /usr/local/bin/links file installed by the www/links port, and will not try for www/links1; everything will seem okay to both portupgrade and a manually-invoked 'make all install' in the docproj port directory. If there is any bug at all, it would have to be a minor portupgrade bug, insofar as portupgrade does the same thing as the Ports Collection's bsd.port.mk when checking dependencies. What I think happened was that portupgrade found that your links port was out of date, chdir'd to its listed origin, www/links, and upgraded it from 0.97 to 2.0. Then, it checked all the installed packages that listed the old links port as a dependency, it hit upon the docproj package, chdir'd to its listed origin, textproc/docproj, checked its dependencies - and everything checked out fine, because there *is* a ${PREFIX}/bin/links binary. Yes, this is a bit unfortunate, but that's the way it works; the only way it could be "fixed" would be to make the www/links1 port install a bin/links1 file, either as a symlink, or as the "real" links file. A symlink would be preferable, because then the "real" browser would still be invoked as 'links', and no doc/ Makefile's would need to be changed. Then, the docproj port could be made to check for ${PREFIX}/bin/links1, so www/links would not satisfy the dependency. This might still create conflicts on a "blind" portupgrade run, because then the newly-installed links1 port would overwrite the links-2.0 bin/links executable.. guess there is no real clean way to handle this :( Well, maybe there is - porting the -dump patch to links-2.0 - but I think I have done enough rambling so far :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE9rlMd7Ri2jRYZRVMRAkzWAKCFDqH/tYqTFxAEiGC7nOsB5eOMBgCglE/z c5rFsnO8FA3oyWziqyQKX0g= =AI01 -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message