From owner-freebsd-ports@FreeBSD.ORG Tue Dec 28 08:28:08 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 E33491065675 for ; Tue, 28 Dec 2010 08:28:07 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from praag.hoster.bg (praag.hoster.bg [77.77.142.10]) by mx1.freebsd.org (Postfix) with ESMTP id 49AFD8FC18 for ; Tue, 28 Dec 2010 08:28:07 +0000 (UTC) Received: from middenheim.hoster.bg (middenheim.hoster.bg [77.77.142.11]) by praag.hoster.bg (Postfix) with ESMTP id CC74C8CA27 for ; Tue, 28 Dec 2010 10:28:04 +0200 (EET) Received: from straylight.ringlet.net (nat125.cnsys.bg [85.95.80.125]) (Authenticated sender: roam@hoster.bg) by mail.hoster.bg (Postfix) with ESMTP id 362185C0B4 for ; Tue, 28 Dec 2010 10:27:56 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 50676b by straylight.ringlet.net (DragonFly Mail Agent) Tue, 28 Dec 2010 10:27:55 +0200 Date: Tue, 28 Dec 2010 10:27:55 +0200 From: Peter Pentchev To: Eygene Ryabinkin Message-ID: <20101228082755.GA4381@straylight.ringlet.net> Mail-Followup-To: Eygene Ryabinkin , Doug Barton , David Demelier , freebsd-ports@freebsd.org References: <4D15D275.6000308@gmail.com> <4D194421.9080304@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-MailScanner-ID: 362185C0B4.A776A X-hoster-MailScanner: Found to be clean X-hoster-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=0.001, required 10, autolearn=disabled, UNPARSEABLE_RELAY 0.00) X-hoster-MailScanner-From: roam@ringlet.net X-hoster-MailScanner-To: freebsd-ports@freebsd.org X-Spam-Status: No Cc: David Demelier , Doug Barton , 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 08:28:08 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 28, 2010 at 10:07:18AM +0300, Eygene Ryabinkin wrote: > 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. :) >=20 > There are two questions that arise with this approach: >=20 > - 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; Two quick thoughts here: - I personally would prefer a human-readable file (and yes, I *can* read XML; that doesn't mean it's easy or I *want* to :) ...so how about a JSON representation? Human-readable, human-editable, but still capable of being formalized and validated - ...and as for an implementation, there is a mini-JSON library in NetBSD's netpgp implementation - src/crypto/external/bsd/netpgp/dist/src/libmj/ in NetBSD CVS > - 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. >=20 > 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. >=20 > 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. >=20 > > 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. :) > >=20 > > 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. >=20 > 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. G'luck, Peter --=20 Peter Pentchev roam@space.bg roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence claims to be an Epimenides paradox, but it is lying. --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNGZ+GAAoJEGUe77AlJ98TqrIP/26VStwjBGhUIBwEbok3gtU+ ivrS1Hdak6GX926HCaiPS1jDYUpMpyt7OTX68AVCTDEBH5E6dEoSfhWaVpmLmsi4 hsjxsBbjrlzqTSZXNQCGJcp7q3EbGF8OoFohZT2a0bzn2+H9+Er0n5WfODkgmC3j IGYLLtolRZCnj7nJhtJwfJr2u5/ptD27EKMkpq+Bdnh21BDUKp001GzrnEnp9Ssp cuzAoCkHEasUgBKhN/Hc2aKT5DiYuLaoFflGmWIt7jnfJ3xJ1Jm/G6MvO4riAhGN WbXLq2lDKJfIye95YEuKpyXTq947HExxneR9z3HfPD29Rv5J3rszhJkG5qTANw8a SxR+uBv+ZWXDYQf6hNo8EW6hj7nPSrvsZjOvfij2zkquKi67fY/dbGr1nFUxsEO+ ASzyQqpKUzJYIpXWrbI719TxQwfTyuN/FKgmOI68UyezkfYf1gXmyBEZdZ6vMJuD g9jZWJPGkTtyPoFidB3RjYo1wBd++Lb5nlhygHlO6C3jIef2pN3+hRki5dVF5Shx uX/NSuijFlZwjEU48Obj3JXmRPB+Km3HvG+aK2fs41tX3nmWr/Gy80zkfUrLEjq9 m8Uk6EgumA2VoaLVu7gJkmTaVtAKXCurMVHmHM6aijdSwjdNpclNF8Mx+HDuyi9j rMCVQvpBDy0suvvEy/0g =ksA3 -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+--