From owner-freebsd-ports@FreeBSD.ORG Tue Jul 26 09:46:42 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D452106566C for ; Tue, 26 Jul 2011 09:46:42 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 19B208FC08 for ; Tue, 26 Jul 2011 09:46:41 +0000 (UTC) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p6Q9RJd0061451 for ; Tue, 26 Jul 2011 11:27:19 +0200 (CEST) X-Ids: 164 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id B2AB320429 for ; Tue, 26 Jul 2011 11:27:56 +0200 (CEST) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id 9B3364CDA; Tue, 26 Jul 2011 11:27:56 +0200 (CEST) Date: Tue, 26 Jul 2011 11:27:56 +0200 From: Michel Talon To: freebsd-ports@freebsd.org Message-ID: <20110726092756.GA90978@lpthe.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Miltered: at jchkmail.jussieu.fr with ID 4E2E889D.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4E2E889D.003/134.157.10.1/parthe.lpthe.jussieu.fr/parthe.lpthe.jussieu.fr/ Subject: Re: Time to mark portupgrade deprecated? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 09:46:42 -0000 Jerry wrote: > While we are on the subject of port management tools, I still use > "portmanager" when a version bump on a port requires that a massive > number of dependencies be rebuild. I have had all too many instances > when both "portupgrade" and "portmaster" simply bombed out and left me > with only a partially updated system, and in many cases, a virtually > useless one. Portmanager would simple get the job done right the first > time. It might be overkill for one or two port upgrades; however, it > works fine on massive projects that seem to bewilder the other two > competing contenders. The "p5-libwww-5*" example in the case of > "portmaster" being a perfect example. This subject of port management tools is a subject i have been much interested in some years ago, and i must say that the problems which seem to surface now in the general consensus, i had discussed them without any echo at the time. Having a system partially updated hence requiring a lot of work to fix with portupgrade happened to me several times. Horrific slowness of portupgrade was perfectly obvious years ago. I think most of the problems come from errors in the ports themselves so are unfixable through ameliorations in the upgrade tools. I think only a more rigorous management of the ports, i mean something like the separation between unstable, testing, stable in Debian, with rigorous procedures for going from one state to the better one could cure this problem, but at the expense of slowing the development. More importantly, only a procedure centered around *binary* packages could possibly lead to a guaranteed decent state of the ports. Centering things around source code can only lead to confusion, incessant messing by both developers and users with various options etc. which can only destabilize the system. Anyways, to come back to port management tools i don't know how portmanager works, but i think that both portupgrade and portmaster have a fundamental flaw in that they both work locally, upgrading one port after another until the job is finished, which means that the state of the machine is constantly modified, possibly into a broken state, without any possibility for the user to know beforehand that he is headed to failure. A proper tool should do a first pass describing exactly the initial state and the final state so that the end user can choose to upgrade or not. This is what Debian apt-get (or aptitude) does, it describes before any destructive action begins what will be removed, what will be installed. This can only work reliably if you have binary packages, otherwise you can never be sure that a source port will compile. The only *BSD i am aware of that has moved in that direction is OpenBSD. From what i hear, people are happy with the management of ports in OpenBSD, while most of people i hear are very unhappy with FreeBSD ports. -- Michel TALON