UPDATING - needs updating?

[Vizion]

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 <wxs at csh.rit.edu> 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 <chcuckles>
>
>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.