Date: Mon, 21 Nov 2005 19:51:13 -0500 From: Randy Pratt <bsd-unix@comcast.net> To: Wesley Shields <wxs@csh.rit.edu> Cc: freebsd-ports@freebsd.org, vizion@vizion.occoxmail.com Subject: Re: UPDATING - needs updating? 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Nov 2005 16:54:21 -0500
Wesley Shields <wxs@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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051121195113.654f311f.bsd-unix>