From owner-freebsd-ports@FreeBSD.ORG Tue Jul 26 11:56:16 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 48E99106566C for ; Tue, 26 Jul 2011 11:56:16 +0000 (UTC) (envelope-from tingox@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 097DE8FC1B for ; Tue, 26 Jul 2011 11:56:15 +0000 (UTC) Received: by vws18 with SMTP id 18so317504vws.13 for ; Tue, 26 Jul 2011 04:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BnsotAf/2DuJQuCEBYLDZ8yQKuJfWTmUoUhJgrJ8T/w=; b=wbaB7mvx0VaE/QPGXEXid5SRXEq3E1fN96LH9LLPIExirwvPKm8RgmQlQC2uQkYPyu gxVSNJ2aLSpvBUt9/Nh0PaLNYAJyrd/M7FZOTyF8ku54OBQFIIygPf7kdUTytB7MqHlD q+XY70R9C2Dip7fdP6dC++6itOo8+IKKxx1E4= MIME-Version: 1.0 Received: by 10.52.174.104 with SMTP id br8mr5057490vdc.145.1311681374962; Tue, 26 Jul 2011 04:56:14 -0700 (PDT) Received: by 10.52.107.194 with HTTP; Tue, 26 Jul 2011 04:56:14 -0700 (PDT) In-Reply-To: <20110726092756.GA90978@lpthe.jussieu.fr> References: <20110726092756.GA90978@lpthe.jussieu.fr> Date: Tue, 26 Jul 2011 13:56:14 +0200 Message-ID: From: Torfinn Ingolfsen To: FreeBSD Ports ML Content-Type: text/plain; charset=ISO-8859-1 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 11:56:16 -0000 Hi, On Tue, Jul 26, 2011 at 11:27 AM, Michel Talon wrote: > 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 The subject we were discussing was portupgrade; if you want to discuss something else, please start a new thread. Thank you. > 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. I would say that "most people your hear" isn't a representative subset of all the people who use ports. In my experience anyway. -- Regards, Torfinn Ingolfsen