From owner-freebsd-ports@FreeBSD.ORG Tue Nov 22 01:07:45 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 3E57416A41F for ; Tue, 22 Nov 2005 01:07:45 +0000 (GMT) (envelope-from vizion@vizion.occoxmail.com) Received: from dukecmmtao02.coxmail.com (dukecmmtao02.coxmail.com [68.99.120.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id B636743D5A for ; Tue, 22 Nov 2005 01:07:44 +0000 (GMT) (envelope-from vizion@vizion.occoxmail.com) Received: from dns1 ([64.58.171.82]) by dukecmmtao02.coxmail.com (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051122010759.CCTC6953.dukecmmtao02.coxmail.com@dns1>; Mon, 21 Nov 2005 20:07:59 -0500 From: Vizion To: Randy Pratt Date: Mon, 21 Nov 2005 17:07:39 -0800 User-Agent: KMail/1.8 References: <200511210839.56424.vizion@vizion.occoxmail.com> <20051121215420.GA68639@csh.rit.edu> <20051121195113.654f311f.bsd-unix@comcast.net> In-Reply-To: <20051121195113.654f311f.bsd-unix@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511211707.40504.vizion@vizion.occoxmail.com> Cc: Wesley Shields , 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: Tue, 22 Nov 2005 01:07:45 -0000 On Monday 21 November 2005 16:51, the author Randy Pratt contributed to the dialogue on- Re: UPDATING - needs updating?: >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. > That is neat >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. Umph well I am trying to work may way towards a web management interface for freebsd with some automatic processing whereever possible-- each to his/her own I guess > >Anyway, I just thought I'd share the approach I came up with in case >others might find it useful or trigger some ideas. Nice approach david -- 40 yrs navigating and computing in blue waters. English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit.