From owner-freebsd-arch Tue Jul 9 13:10:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E11337B400; Tue, 9 Jul 2002 13:10:13 -0700 (PDT) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16A0B43E31; Tue, 9 Jul 2002 13:10:12 -0700 (PDT) (envelope-from simonm@sm.dnsalias.com) Received: from sm.dnsalias.com ([213.107.104.1]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020709201010.FJUR19225.mta07-svc.ntlworld.com@sm.dnsalias.com>; Tue, 9 Jul 2002 21:10:10 +0100 Received: from sm.dnsalias.com (localhost [127.0.0.1]) by sm.dnsalias.com (8.12.4/8.12.4) with ESMTP id g69KA9pU013609; Tue, 9 Jul 2002 21:10:09 +0100 (BST) (envelope-from simonm@sm.dnsalias.com) Received: (from simonm@localhost) by sm.dnsalias.com (8.12.4/8.12.4/Submit) id g69KA7Ul013606; Tue, 9 Jul 2002 21:10:07 +0100 (BST) To: Rahul Siddharthan Cc: John Baldwin , arch@freebsd.org, Dan Nelson Subject: Re: Cleaning old packages (was: Package system flaws?) References: <20020709161953.GA69779@lpt.ens.fr> <20020709171417.GA69932@lpt.ens.fr> From: Simon Marlow Date: 09 Jul 2002 21:10:07 +0100 In-Reply-To: <20020709171417.GA69932@lpt.ens.fr> Message-ID: Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Rahul Siddharthan writes: > That seems rather ambitious, and too drastic a change, to me. What > I'd like to see is probably more like, the gfoo port needs gtk+ 1.2.6 > or above, but not gtk+ 2.0 and above (incompatible) and not gtk+ 1.2.5 > or below (buggy). There should be some way to specify this in the > makefile of the port, so that any port-management program like > portupgrade can make use of the information. A port can't know which versions of a library it will be compatible with ahead of time. Only the port itself knows which older versions of itself are compatible with the current version, so the information about whether an upgrade is safe or not should reside in the port which is being upgraded. This why the suggestion of using capability names or APIs to specify the functionality is a better way, but I think it's perhaps a level of abstraction too far. I've always been annoyed by the way the ports system spams older versions of ports with newer ones. It isn't safe to do in general, so IMO the ports system should at the least just refuse to continue if it finds it needs to do this. Then if the specification for a port had some way to say that it was safe to upgrade certain versions to the new version, it could go ahead (deleting the old one first, of course). So here's my suggestions: - Allow a port to specify a range of versions which are safe to upgrade to the current version without user intervention. - The ports system should *not* automatically install a new version of a port over an old one. If the port says it is safe to do so, then remove the old port and install the new one. Allowing dependencies to specify version ranges would help reduce the number of upgrades required, but wouldn't otherwise improve matters. Also it requires updates to N ports rather than 1 for each dependency, so is far more error prone. (disclaimer: I'm lazy and haven't looked at libh, so I apologise if this is old news) Cheers, Simon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message