Date: 17 Oct 2002 10:48:36 -0700 From: swear@attbi.com (Gary W. Swearingen) To: Peter Pentchev <roam@ringlet.net> Cc: "Gary W. Swearingen" <swear@attbi.com>, freebsd-doc@freebsd.org Subject: Re: Curious doc/en*/Makefile Checkout/Delete cycling by cvsup Message-ID: <gh7kgh553f.kgh@localhost.localdomain> In-Reply-To: <20021017060518.GB371@straylight.oblivion.bg> References: <4zlm4z74c7.m4z@localhost.localdomain> <20021016070026.GU372@straylight.oblivion.bg> <gi7kgi6z2o.kgi@localhost.localdomain> <20021017060518.GB371@straylight.oblivion.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Pentchev <roam@ringlet.net> writes:
> 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. [snip]
Sounds like portupgrade is working OK. Like you indicate later, the fix
lies elsewhere.
> 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.
It seems to me that the problem here is that docproj doesn't like the
current version of a port and forces one to mess up the current version.
You fix seems to just mess it up differently. If docproj can't use the
current version it ought to kluge up an alternate version with different
names so it doesn't break the current version. The docproj scripts
would, of course, have to use the alternate names (or alternate PATH).
> 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.
So when one tries to run the current-version "links", one gets the
alternate one? That's nasty.
> 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
The links1 port already has that nasty feature. And it leaves the
current version in the package database as if it were still valid.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?gh7kgh553f.kgh>