From owner-freebsd-ports@FreeBSD.ORG Tue Nov 22 01:11:39 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 222BB16A41F for ; Tue, 22 Nov 2005 01:11:39 +0000 (GMT) (envelope-from bsd-unix@comcast.net) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B2643DA9 for ; Tue, 22 Nov 2005 01:11:13 +0000 (GMT) (envelope-from bsd-unix@comcast.net) Received: from kt.weeble.com (pcp858615pcs.ptchar01.fl.comcast.net[68.56.224.228]) by comcast.net (sccrmhc12) with SMTP id <2005112200511201200250ice>; Tue, 22 Nov 2005 00:51:17 +0000 Date: Mon, 21 Nov 2005 19:51:13 -0500 From: Randy Pratt To: Wesley Shields Message-Id: <20051121195113.654f311f.bsd-unix@comcast.net> In-Reply-To: <20051121215420.GA68639@csh.rit.edu> References: <200511210839.56424.vizion@vizion.occoxmail.com> <20051121191335.GA56240@csh.rit.edu> <200511211259.08340.vizion@vizion.occoxmail.com> <20051121215420.GA68639@csh.rit.edu> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org, vizion@vizion.occoxmail.com 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: Tue, 22 Nov 2005 01:11:39 -0000 On Mon, 21 Nov 2005 16:54:21 -0500 Wesley Shields wrote: > 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 don't trust that kind of thing to memory. Each time I update I move the UPDATING to UPDATING.previous, then cvsup. A simple diff script shows the items of interest between the two. This seems to work well enough. Here is a section of my ports updating script: -----------begin excerpt-------------- # Check UPDATING (Skip if same as last session) updating_last="/usr/ports/UPDATING.previous" updating_new="/usr/ports/UPDATING" if [ ! -e $updating_last ]; then touch $updating_last echo "created empty $updating_last" fi updating_last_date=`ident $updating_last | tail -1 | cut -d " " -f 8` updating_new_date=`ident $updating_new | tail -1 | cut -d " " -f 8` if [ $updating_new_date = $updating_last_date ]; then #echo "nothing new" else /usr/sbin/mixer vol 75:75 /usr/local/bin/play /home/rpratt/sounds/alert.wav diff $updating_last $updating_new | awk -F "> " '{print $2}' | less cp $updating_new $updating_last echo "If UPDATING contained special instructions that affect portupgrading" echo "then a manual update is probably needed." echo echo "Continue with portupgrading? y/n:"; read YES_NO if [ $YES_NO = "n" ]; then exit fi fi -----------end excerpt-------------- Its handy to have the ports updating script stop at that point so that manual updating of items can be done if needed before proceeding. Granted, the above script isn't perfect since corrections to older items will also show up in the diff output as fragments. Usually those can be ignored since that updating step has already been completed. I thought about using the date of the last cvsup from the output of ls -l /usr/sup/ports-all/checkouts.cvs\:. as a basis of where to start reviewing UPDATING on machines where I have not been making the UPDATING.previous copies. That date is the most reliable method of determining when the last ports cvsup was ran. It would take a bit more scripting to use that approach. A side benefit to doing something along these lines is that I am forced to look at UPDATING if it has changed and my portupgrade won't proceed until I deem it proper. > > >> 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 Using HTML is probably unnecessarily complicating things since most people don't use browsers in doing portupgrades. It'd probably be best to stick with plain text. Anyway, I just thought I'd share the approach I came up with in case others might find it useful or trigger some ideas. Best regards, Randy