From owner-freebsd-ports@FreeBSD.ORG Mon Nov 21 21:54:09 2005 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D4BF16A420 for ; Mon, 21 Nov 2005 21:54:09 +0000 (GMT) (envelope-from wxs@syn.csh.rit.edu) Received: from syn.csh.rit.edu (syn.csh.rit.edu [129.21.60.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 212D843D80 for ; Mon, 21 Nov 2005 21:54:08 +0000 (GMT) (envelope-from wxs@syn.csh.rit.edu) Received: from syn.csh.rit.edu (localhost [127.0.0.1]) by syn.csh.rit.edu (8.13.3/8.13.1) with ESMTP id jALLsLGi069041; Mon, 21 Nov 2005 16:54:21 -0500 (EST) (envelope-from wxs@syn.csh.rit.edu) Received: (from wxs@localhost) by syn.csh.rit.edu (8.13.3/8.13.1/Submit) id jALLsLpI069040; Mon, 21 Nov 2005 16:54:21 -0500 (EST) (envelope-from wxs) Date: Mon, 21 Nov 2005 16:54:21 -0500 From: Wesley Shields To: Vizion Message-ID: <20051121215420.GA68639@csh.rit.edu> References: <200511210839.56424.vizion@vizion.occoxmail.com> <20051121191335.GA56240@csh.rit.edu> <200511211259.08340.vizion@vizion.occoxmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511211259.08340.vizion@vizion.occoxmail.com> User-Agent: Mutt/1.5.11 Cc: freebsd-ports@freebsd.org Subject: Re: UPDATING - needs updating? 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: Mon, 21 Nov 2005 21:54:09 -0000 On Mon, Nov 21, 2005 at 12:59:07PM -0800, Vizion wrote: > On Monday 21 November 2005 11:13, the author Wesley Shields contributed to > the dialogue on- > Re: UPDATING - needs updating?: > > >On Mon, Nov 21, 2005 at 08:39:55AM -0800, Vizion wrote: > >> Hi > >> > >> I have noticed that some earlier notices relating to some ports in > >> UPDATING appear as though they have been made out of data by newer notices > >> (e.g kde 20050804 seems to replace 20050324) and sometimes the > >> instructions conflict with one another. While I presuime the latest notice > >> always takes precedence I wonder if it would be possible to have notices > >> that are no longer current removed from UPDATING. > > > >I think this is probably a bad idea, simply from a historical > >perspective. If I wanted to chase down a bug that was available only > >for a specified time period I would like to know the corresponding > >UPDATING entries. > My focus comes from the primary purpose of UPDATING - to help check the best > way to update one's own ports(e.g the info on kde). Hence scanning a list of > ports affected by UPDATING at the time of updating does seem best suited for > that purpose and I wonder if the non current data might therefore be better > shifted to something like UPDATING.history to fulfill the very real need you > identify. I just remember the last entry I read. If you can't remember it you can manually mark it or write it down somewhere. I think forcing people to look in two different files is just making it more difficult than it needs to be. > >> I know I would find it useful to have an html version of UPDATING with an > >> index page by port with a link to the notices. How easy it would be to do > >> this automatically as UPDATING is upfated I do not know but I throw the > >> idea out there in case anyone feels like catching it. > > > >I believe freshports.org can do this already, though backwards. Rather > >than looking through UPDATING for links to the individual ports you can > >find the corresponding entries in the individual ports themselves (see > >www.freshports.org/x11/xterm as an example). > > Yep I am aware of that - but backwards is not what is needed in the contect od > using UPDATING when updating one's systems. I see the hml index list as > enabling one to scan the list of ports referred to on UPDATING and use that > index to extract the information relevant to one's own system(s). If nothing like this has been done already I'll work on a solution soon. I think it's a good idea, though it may be difficult to catch all the entries for a given port as there is no well defined syntax to follow in the updates. I'll have to think about this a bit more... -- WXS