On Saturday September 13 2003 04:41 pm, Brant Fitzsimmons wrote:
> HaywireMac wrote:
> >On Sat, 13 Sep 2003 16:09:59 -0500
> >
> >Dennis Myers <[EMAIL PROTECTED]> uttered:
> >>I know cause I just did it using Tom B.s instructions.
> >
> >basically it would be urpmi --update --auto-select?
>
> Here's what I use to update.
>
> urpmi -v --auto-select --allow-nodeps --allow-force
> --no-verify-rpm
>
> -v to see everything that going on
> --auto-select to update everything that needs to be updated
> --allow-nodeps to allow you to install without checking
> dependencies if needed
> --allow-force to allow you to force the installation if needed
> --no-verify-rpm to keep it from complaining about bad gpg
> signatures
>
> That'll do it.
With often dire results. The allow --allow-nodeps --allow-force
being the BAD offenders. Here's what I've gravitated to. I install
several 'trusted' mirrors that I have some current confidence in.
It's a movin target, now I'm currently usin uninett, sunsite,
club-internet.fr, a PLF source (also club-internet) simultaneously
and then update several times a day with
tom # cook (that's all I need to type ;)
alias cook='urpmi.update -a -f --wget && urpmi --wget
--no-verify-rpm --auto-select -v' (in /etc/bashrc)
I've found --wget much slower than curl, but more reliable.
It'll keep on tickin, takes a lickin, when the default curl will
fail on unwilling mirrors. --no-verify-rpm gets by bad package
signin, still plaguing cooker as they move to a new signature
model. NBFD, anyway. The last -v just gives verbose output. The
dbl ampersand in the middle just says, 'don't run this next command
unless the last one completed successfully'. When I see major
updates I run 'upall' an login/out, restartin the X server with
<Ctrl+AltBspace> in between. (alias upall='rpm --rebuilddb &&
updatedb && update-menus -n && ldconfig')
There are a few situations from time to time when --allow-nodeps
--allow-force might be called for or needed, but those are usually
best avoided by being a cookerer. By that I'll just say again,
Y'all shouldn't be runnin cooker unless you subscribe to an read
the cooker and CHRM (change log) mailin lists. (I know you do
Brant, so I'm surprised you cavalierly use force, nodeps), it's a
must before you do updates. Need for force or nodeps will have
already been suggested by the developers or other cookerers.....
when called for in rare instances, an then only for certain rpms.
Just as often as not, the better solution is to the d/l the current
src.rpm for the package an rebuild it yourself.
The only time I've ever had problems, cooker being my only
installed system for years, is when I disregard this, my own,
gathered mostly from others advice. Other than that, it's always
been better than the last (what some of y'all call) 'stable'
release. Just takes a little more effort. IE, updating with --auto,
or a cron job is an equally BAD idea.
Case in point, a little more'n a week ago a very bad initscripts
rpm update was on the mirrors (shortly before RC2). I woke up, made
some coffee, an typed 'cook'. THEN read the cooker an CHRPM lists.
Sure enough, as I could'a been forewarned, I'd just updated to an
initscripts package that fubar'd many of my /etc/initd* links. In
my case it also wiped a bunch of /proc subdirs. I should'a read the
lists first ;( A fixed package was available in short order.
It soon became apparent that a fresh install of RC1, an update
to current cooker would be needed for my situation. The whole deal
was only my negligence. Still, it got me off my butt to take a look
at the new installer ;)
--
Tom Brinkman Corpus Christi, Texas
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
