From owner-freebsd-ports Mon Nov 20 05:08:25 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA05701 for ports-outgoing; Mon, 20 Nov 1995 05:08:25 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA05696 for ; Mon, 20 Nov 1995 05:08:20 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA19646; Mon, 20 Nov 1995 13:05:28 GMT From: Michael Smith Message-Id: <199511201305.NAA19646@genesis.atrad.adelaide.edu.au> Subject: Re: Proposal 3: Non-executable file in *_DEPEND To: asami@cs.berkeley.edu (Satoshi Asami) Date: Mon, 20 Nov 1995 13:05:27 +0000 () Cc: msmith@atrad.adelaide.edu.au, ports@FreeBSD.ORG In-Reply-To: <199511201243.EAA00811@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 20, 95 04:43:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4347 Sender: owner-ports@FreeBSD.ORG Precedence: bulk Satoshi Asami stands accused of saying: > > * Pardon my ignorance, but is there a PKG_DEPENDS, to list packages that the > * current item depends on? > > No, the package names of dependencies are not in the ports Makefiles. > Only the paths (e.g., ${PORTSDIR}/lang/tcl) are there, and your lovely > make will cd into that directory to do "make package-name" to retreive > the package name from that Makefile. Can we have one then? 8) On the basis of : for item in PKG_DEPENDS if item not installed and package available install package, continue if item not installed and port available install port, continue complain Seriously, I understand that this is hardly going to happen overnight; I'm just looking to stir up a bit of discussion as the whole prepackaged thing is the current bee in my bonnet 8) > This is a neat idea, but the problem is that this would require a > major change in the paradigm (see above). Also, I'm not exactly sure > how manageable this will be, as we have ports depended from all over > the place, checking for package dependencies when a new version comes > out can be pretty hard. The baseline idea is to come up with a scheme which is simpler. I'm not sure if this is necessarily the right way however. My thinking is prompted by the recent questions wrt. the new fvwm port - I'm fairly sure that it would have compiled fine against any recent version of xpm, but because the xpm version was bumped in the interim, some confusion ensued. > Right now, we have a sort of collapsed scheme that makes this all very > simple. It's also probably too anal, but I'm afraid to fix it would > complicate the (already complex) picture too much. Sometime when I have a keyboard I can actually find the keys on, I'll try to put some coherent thoughts together. I spent a little time recently looking at how the RedHat Linux people do things. They're a little more rigid in their pacakge definition rules, but the "rpm" tools looked fairly similar in feature set to the pkg_* tools, so I tinkered with their graphical front end with a vague idea to making it work under FreeBSD. They have some interesting ideas, but their code is pretty awful. > * And as well, a PACKAGE_USES entry to indicate other packages that aren't > * required, but _are_ used (for extra features, etc). > > This has been suggested a few times, but I still can't understand what > we can do with this. If pkg_add is not going to pull it in > automatically (like RUN_DEPENDS, etc.), the most we can do is to put a > printf that will print out a message -- then how is this different > from just putting in an "@exec echo" line in the pkg/PLIST? Because a hypothetical interactive installer will pop up a dialog and say "The package you have installed can also make use of the following packages to provide extra functionality. Check each of the additional packages that you wish to install and click OK" or "The package you are about to remove is used by the following packages. These packages may fail or produce unexpected results if this package is removed. Check each package you also wish to remove and click OK, or click Cancel to keep everything." It would also be nice if _everything_ was listed in the PLIST file, rather than the current shorthand of listing only directories which contain files specific to the package. This breaks with things like Tcl/Tk, where you may modify or add things to a directory, and then when you pgk_delete/ pkg_add to upgrade, you lose your changes. Unless things have changed recently, pkg_delete doesn't use rm -rf either, so packages with specified directories containing subdirectories don't get cleaned out. It's also necessary in order to provide a mechanism for verifying the installation of a package, and determining whether the components of a package have changed since they were installed. If anyone's really keen, they could start thinking about pkg/ICON too 8) > Satoshi -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[