Date: Thu, 17 Oct 2002 09:05:18 +0300 From: Peter Pentchev <roam@ringlet.net> To: "Gary W. Swearingen" <swear@attbi.com> Cc: freebsd-doc@freebsd.org Subject: Re: Curious doc/en*/Makefile Checkout/Delete cycling by cvsup Message-ID: <20021017060518.GB371@straylight.oblivion.bg> In-Reply-To: <gi7kgi6z2o.kgi@localhost.localdomain> References: <4zlm4z74c7.m4z@localhost.localdomain> <20021016070026.GU372@straylight.oblivion.bg> <gi7kgi6z2o.kgi@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Wed, Oct 16, 2002 at 11:03:27AM -0700, Gary W. Swearingen wrote:
> Peter Pentchev <roam@ringlet.net> writes:
>
> > The doc build needs the www/links1 port; the 'dump' option support was
> > not really merged into links 2.x.
>
> So is there a bug in www/docproj/Makefile or "portupgrade", or is this
> just something that one is expected to manage by hand?
>
> From www/docproj/Makefile:
>
> RUN_DEPENDS= instant:${PORTSDIR}/textproc/sgmlformat \
> ...
> ${PREFIX}/bin/links:${PORTSDIR}/www/links1 \
>
> But from "portupgrade -nR docproj":
>
> - www/links (links-2.0_1,1)
>
> (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
--
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.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)
iD8DBQE9rlMd7Ri2jRYZRVMRAkzWAKCFDqH/tYqTFxAEiGC7nOsB5eOMBgCglE/z
c5rFsnO8FA3oyWziqyQKX0g=
=AI01
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021017060518.GB371>