Date: Mon, 28 Aug 1995 01:40:43 -0700 From: asami@cs.berkeley.edu (Satoshi Asami) To: jkh@time.cdrom.com Cc: paul@freebsd.org, ports@freebsd.org Subject: Re: Dependencies Message-ID: <199508280840.BAA03894@silvia.HIP.Berkeley.EDU> In-Reply-To: <2371.809598269@time.cdrom.com> (jkh@time.cdrom.com)
next in thread | previous in thread | raw e-mail | index | archive | help
* Totally Contrived Example: I need foomake v3.51 in order to compile
* /usr/ports/games/galacticGenocide and it lives in /usr/local/bin/foomake.
* HOWEVER, foomake v3.50 had a bad bug that makes it fall over with
* galacticGenocide's makefile, so it's not enough to simply check that
* /usr/local/bin/foomake is there, it has to be the correct version of it.
On the other hand, the current pkg_add is sometimes accused of being
"too picky" about the versions; i.e., when it doesn't really matter
whether you have foomake v3.50 or v3.51, it goes and pkg_adds foomake
v3.50 because you have pkg_deleted it before you pkg_added v3.51 and
the galacticGenocide package was compiled with foomake v3.50.... ;)
Also, how are we going to figure out the package name using the
EXEC_DEPENDS lines (e.g., "foomake:${PORTSDIR}/devel/foomake")? The
user may have installed foomake from a package and not have
${PORTSDIR}/devel/foomake. (And it can be an old version, etc.,
etc...).
I'm not saying you are wrong, they both have their merits and defects,
but the current scheme of requiring root (or whoever installs the
packages) to have /usr/local/bin and /usr/X11R6/bin in the search path
seems like the lesser of evils....
* With the current scheme, you're screwed. With a pkg_info reliant scheme,
* `pkg_info -e foomake3_50' will do the right thing.
You mean "...3_51"? :p
Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508280840.BAA03894>