From owner-freebsd-ports@FreeBSD.ORG Tue Dec 28 07:07:23 2010 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 509901065670; Tue, 28 Dec 2010 07:07:23 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 608A78FC08; Tue, 28 Dec 2010 07:07:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=EjJ28WJMAkLADYLODbrIqvH6LY9LyfsHCGI952QXswc=; b=qRVFxK9gNs5Zjltx5/fTXMyfEpVhAuFj5MW/OJ9lxIr/U/euhekWFZW+CQEPgkJvg6XPHnqQVVP0AI3EkR25j2yBXcyv7kRfWd8Ios+fjM8JDpyNGzoyTHIXHS6iMq40CXLzwmWJT81rw8WFWVO+tVJqTzO+9fpRmwi5rr135tbO4zzNsOpcFmAwmhseBCc7rt7+2GBidmofPQB2W3n9HAUiXbzkBm7uqdi5FlZ456YpyexR4nq56rQH13oDnetgXINF+08+GtkXt4y2uDyih6LzzRXc8i/KuBib/KCs/JD/f7zd5X2k+OqNNKHY1nU0isB3lp2dAkNU03V7yOYqgQ==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1PXTeS-0009KO-TU; Tue, 28 Dec 2010 10:07:21 +0300 Date: Tue, 28 Dec 2010 10:07:18 +0300 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4D15D275.6000308@gmail.com> <4D194421.9080304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D194421.9080304@FreeBSD.org> Sender: rea@codelabs.ru Cc: David Demelier , freebsd-ports@freebsd.org Subject: Re: portmaster: print /usr/ports/UPDATING on update 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, 28 Dec 2010 07:07:23 -0000 Mon, Dec 27, 2010 at 05:57:53PM -0800, Doug Barton wrote: > The Real AnswerTM is that we need a tool with striking similarities to > portaudit. The basic idea would be that UPDATING entries would be done > in xml, and then the user can either run portupdating (or whatever the > name ends up being, that's a really bad name but I suck at naming tools) > either by default for their whole system, or vs. a specific port. I > would strongly recommend that the behavior, command line options, etc. > be consistent with portaudit. Download it and check the man page if > there are any questions. :) There are two questions that arise with this approach: - we should find a way to keep an old UPDATING file in place; obviously, it can be easily created from the XML file, but currently UPDATING is delivered via CVS and it will be good to allow this behaviour even with the XML'ized version; but keeping the plain-text UPDATING in CVS while UPDATING.xml will be used is a bad idea -- UPDATING will be non-master file, so its history will be redundant. From the other hand, we have no XML tools in the base tree, so UPDATING can't be easily created from the XML version at the user machine; - currently, UPDATING has only port names, but not their versions; one takes the entry timestamp and if he had not yet upgraded the relevant port(s) after this timestamp, then the corresponding entry is for him. I see there two cases: a) there is a specific port version at which some crucial change that demands the UPDATING entry had happened; if the version specification will be included in UPDATING, then we won't even need the timestamp -- one should just take the currently installed version and the version to be installed; the the entry's version lies between those two, user will surely need to read the UPDATING entry; b) there is a infrastructural changes that affect all or some ports that will be built after some date; again, the logics of choosing the entry to be presented is the same as above, but one should use timestamps, not ports versions. But having thinked about this a bit, now I am favoring another approach: one should not rely on the portmaster/portupgrade/OtherTool to present the UPDATING entries: the best place is the ports infrastructure itself (or pkg_install suite). This way, any tool that will do upgrades will receive the UPDATING stuff for free. Currently I am trying to figure out if it will be sufficient to have the appropriate machinery in the pkg_delete tool: the old port version and timestamp are already there; the new timestamp is more-or-less the current date; the only needed piece is the new port version. It can be provided via the environment variable by the portmaster-like tool; such variable will trigger the processing of the UPDATING file. This is rather rough plan, feel free to correct/criticize it or show why it is not doable using such approach. > The other thing this entails is portmaster actually storing > information of its own completely aside from /var/db/{pkg|ports}. I'm > really sort of nauseous about that whole idea since it's a slippery > slope that I don't want to travel down. But I'm not seeing any other > way to accomplish the task of "make sure that the user knows that they > should read UPDATING" without doing something very much like this. Of > course, if someone else has a better idea, I'm all ears. :) > > What I do _not_ want to do is write an "UPDATING text file parser" > myself. Not only do I think that's a bad idea generally, it's not a > project that I am at all interested in, and I don't see it as > something that should be part of portmaster to start with. I could be > talked into the UPDATING.xml project if someone were to come up with > funding for it, but (just being frank and honest) it's too big a > project for me to tackle on a volunteer basis atm. I had shown the simple shell script that will parse the UPDATING and present the entries for the given port if the fall into the "last N days" category. If you had missed it -- ping me, I'll show it to you once again. -- Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]