Tom Brinkman wrote:
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.
Please read my email in response to your earlier comments. (I don't know why I post if those posting responses are not going to read my post before commenting.)
T o calarify, I didn't mean that you hadn't read my response to your reponse. I meant...Aaaaaaaaa... nevermind, just see my earlier response. The bed is calling me.
At no time did I use --force. Why would I use an option to negate the other options I passed to urpmi (--allow-nodeps and --allow-force)? It just doesn't make sense. I don't use them cavalierly. Since, as I have said before, it asks me if I want to use those options I have them at my disposal should I feel the need to use them. I have a gun, whose ownership and use I don't take cavalierly either, but I have it should I be in a situation where I would need to use it.
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 ;)
-- Brant Fitzsimmons [EMAIL PROTECTED] ___________________________________________________________________
Linux user #322847 | Linux machine #207465 | http://counter.li.org/ AMD Duron 1.3GHz | Mandrake 9.1 | Kernel 2.4.21-0.16mm-mdk KDE 3.1.3 | Mozilla 1.4 Mail Client Uptime: 03:05:01 up 7 days, 14:21, 1 user, load average: 0.11, 0.07, 0.08 ___________________________________________________________________
"All truth passes through three stages. First, it is ridiculed.
Second, it is violently opposed. Third, it is accepted as being
self-evident."
-Arthur Schopenhauer (1788-1860)Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
