From owner-freebsd-ports@FreeBSD.ORG Tue Dec 28 13:54:00 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 F22671065673 for ; Tue, 28 Dec 2010 13:54:00 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A46738FC0A for ; Tue, 28 Dec 2010 13:54:00 +0000 (UTC) Received: by gwj21 with SMTP id 21so5189553gwj.13 for ; Tue, 28 Dec 2010 05:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=aQBatSHCdk2FKaMxbvv03Qshrjp4yvEj9r6vzE71PWY=; b=RkO3SsP2pGDRiPVTXTz2VzI/poK5xj3Bgjw20bBsVe2ADo9DTve/FiizsB++7QlI// ZL20rfbKhjglDqhDxomDYoUApDcpcawxVewVOJq9jZqJbGuSsE51FBsxxkLI7gvzqvYS XKUbuGnEJcQFSf8hhNb4GLGFHZns9L2ol7wM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=J9Kg34lZc/39ZT5meQObYCsYLzS7F/NKOzJH+noGNgDFpXlk2IzBzosFYsr/LEaMvX 5r4y0abTEKVpM879jCPU4T1eZG4Ff13dYdJRw/QpfpPsVqe1q69P3jb25NGiqoLgm+AL sLNG2ZDTsD3TvHSOyE2SjkZ2aF6vdZzUAnGPw= Received: by 10.236.109.148 with SMTP id s20mr8278131yhg.52.1293544437396; Tue, 28 Dec 2010 05:53:57 -0800 (PST) Received: from centel.dataix.local ([99.181.145.144]) by mx.google.com with ESMTPS id i61sm7283443yha.47.2010.12.28.05.53.54 (version=SSLv3 cipher=RC4-MD5); Tue, 28 Dec 2010 05:53:55 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4D19EBF0.4060405@DataIX.net> Date: Tue, 28 Dec 2010 08:53:52 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101210 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Doug Barton References: <4D15D275.6000308@gmail.com> <4D194421.9080304@FreeBSD.org> In-Reply-To: <4D194421.9080304@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 13:54:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/27/2010 20:57, Doug Barton wrote: > On 12/25/2010 03:16, David Demelier wrote: > | Hi, > | > | A lot of people always forget to read UPDATING (that's normal we'll are > | humans). > | > | Each entry in UPDATING is like "AFFECTS: users of net-mgmt/flowd" so if > | an update of net-mgmt/flowd is available and a *recent* entry in > | UPDATING talks about then print the message. > | > | This can prevent a lot of breakage and useless noise on lists. What do > | you think ? > > I've caught up on this thread now, kicked it around with the cool cats > in #bsdports@efnet, and here is my opinion, to the extent I have > anything to say about it. :) > > 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. :) > > This is not really as hard as it sounds, as the entries for UPDATING > would not have to be very complex xml-wise, and there is already > existing infrastructure that we can leverage to make things easy for the > committers. Also having this information in XML format will make it > easier for other programmatic solutions down the road. > > ~From the user side, we're not really losing anything by not having > "human readable" output readily available, since 99% of users will just > want to be able to know what entries are relevant to their installation > anyway. Of course one useful option for the portupdating script would be > "print all of the entries since X date" so that if someone had a purpose > for reading the plain text it could be dumped to a file, parsed, or what > have you. Meanwhile, all of the ports management tools could benefit > from having _a_ common tool to do this, similar to how we've all > benefited from portaudit. > > But since that's not likely to happen tomorrow, what I do anticipate > adding to portmaster is a "thingy" to stat the update time on > $PORTSDIR/UPDATING and then notify you if you have not viewed the file > since the last time it was updated. The code to compare/store timestamps > I already have, but this also entails adding an option to turn off that > behavior, etc. etc. I'm currently debating whether to try to get this > into the version of portmaster I release soon'ish, or wait till after > the upcoming base releases. > > 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. > > > > | Merry Christmas and happy holidays ! > > Same to you. :) > > > Doug > In a way I sort of agree with this but on the other hand I look at it in this way. 1). The only time UPDATING affects you is if you are building from ports, in a sense 2). When upgrading a port you only need the entry that effects that port and the ports that depend on it. 3). Also when upgrading a port you only need the entries that is only relevant up-to that version of the port you would be upgrading to. 4). Also UPDATING is only useful if you have a ports tree installed and will be upgrading using the ports tree. So with the above said, 1). Why should there be a tool in user-land(world) if this matter deals directly with upgrading ports via a ports tree. 2-3). If the entry is only relevant to the version of port being upgraded to and the ports it depends on then there should be something available that is more local to the port being developed rather than an outside tool. 4). If this is only relevant to when a ports tree is available and binary packages are not being used then there is no sense in injecting user-land tools into the world. Conclusion & with all due respect XML & JSON along with user-land tools are a lame temporary solution to a longer standing problem and there is a lack of framework that allows a developer to properly inform the user of changes that might effect an upgrade. ``bsd.updating.mk'' might be a better longer term solution that would allow a maintainer to alert the user with a simple "All done reading ?" and a spill of output that effects that port up-to version being upgraded. And yes XML and-or JSON could surely play a part in this as well. JST Regards, - -- jhell,v -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNGevwAAoJEJBXh4mJ2FR+r08H+wfNRp8Ks0VfZEbUqDbuvea+ kUPYSe1xvYkoC5CBiA3bBjEmAb7YIShMGemS3sU+Jc3FoZjAS3irbsQahpCEsooj 3gt1p72vaaKwE5L1yQUoiXH+gPxCobMS7fwn1hDz1lbZqSMb75jn/MZZ+8qcvXWw N8APAeFGNbs4xA94FTa39xzo5yZjF73lrEzHc+9NdbrknN21/EBE3p5DgMNS+aX1 Z9uaDqERKPFf+19hCb+VcVBxoaRYv1P7UVeAz+GnNa/EtccPK0iIww1TNX9n+qnS EaO58vgQDcAOePjBYrWXoUDbN+lkUYIvtZSrxCTwBdOdxOCRHEp9lNihYyDuiEQ= =EsqM -----END PGP SIGNATURE-----