From owner-freebsd-ports@FreeBSD.ORG Thu Mar 20 08:05:31 2008 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 2E62C106566B for ; Thu, 20 Mar 2008 08:05:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with SMTP id DB9758FC16 for ; Thu, 20 Mar 2008 08:05:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30173 invoked by uid 399); 20 Mar 2008 08:10:15 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 20 Mar 2008 08:10:15 -0000 X-Originating-IP: 127.0.0.1 Date: Thu, 20 Mar 2008 01:05:27 -0700 (PDT) From: Doug Barton To: Michel Talon In-Reply-To: <20080320001048.GA39125@lpthe.jussieu.fr> Message-ID: References: <20080320001048.GA39125@lpthe.jussieu.fr> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-ports@freebsd.org Subject: Re: Utility for safe updating of ports in base system 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: Thu, 20 Mar 2008 08:05:31 -0000 On Thu, 20 Mar 2008, Michel Talon wrote: > Doug Barton wrote: >> So, I renew my inquiry. :) Is portmaster a suitable candidate to fulfill >> the role of the utility described, and if not, why not? > > At the risk of being flamed, I certainly hope not. :) > i would venture to say that such an utility > should be able to upgrade things based of *binary* packages, and > consequently that portmaster is not a suitable candidate. That ability is not included in the current requirements document, and was not specifically mentioned the last time we had the discussion on the list. If the portmgr folks intend that to be a requirement, the current ideas list entry should be amended. > For example > pkg_add installs a binary package, if you want to compile and install > you run "make all install clean" in the ports tree. Um, you lost me there. > One of the > requirements of an upgrade system is predictability, this can only > be achieved by using binary packages. You gain a certain amount of flexibility with packages, at the expense of being able to customize things. As long as the user understands that, then it's fine. > Another requirement, in my opinion, > is speed, and the lack of speed, which is completely hidden when you > compile your packages will be immediately apparent if you try to use > packages. Indeed portupgrade has options -P and -PP to work with > packages which could serve as a prototype for a "pkg_upgrade" written > in C, except that they work poorly, and in particular run slowly. Where do you think the slowness is? > In my opinion, an example of a correct "pkg_upgrade" type programm > written in C++ is the Debian apt-get. It works predictably, fast, etc. > One of its features, that i consider very important for correct > operation, is that it computes the list of all packages to be deleted > and all packages to be installed and asks the user if he agrees before > doing anything. Why do you consider this an important feature? (I'm not disagreeing, just curious about your thought process here.) > It fetches all necessary packages before installing or > deleting anything. That seems sensible, thanks for mentioning that bit. > Hence you can be sure that the upgrade process will > not end in a mess if something crashes in the middle, like it is the > case with all present standard FreeBSD upgraders. Not sure if this helps the situation you're referring to or not, but portmaster will by default make a backup package of each port that it updates, so if something dies in the middle you could back out of it by hand if you need to. Now all that said, I'd love to see us move to a much more robust package management system, or even just a better interface to the one we have. The problem is that I don't have the time to do that as a volunteer project, and I don't think anyone else does either. :) Doug -- This .signature sanitized for your protection