public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64]  Re: CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"
Date: Tue, 25 Mar 2008 03:52:48 +0000 (UTC)	[thread overview]
Message-ID: <pan.2008.03.25.03.52.47@cox.net> (raw)
In-Reply-To: 5bdc1c8b0803241822v267dcacl64108b01cf53b3b4@mail.gmail.com

"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0803241822v267dcacl64108b01cf53b3b4@mail.gmail.com, excerpted
below, on  Mon, 24 Mar 2008 18:22:20 -0700:

>>  Of course revdep-rebuild wants to rebuild lots and lots of stuff

I see you solved the original problem, but this bit worries me.

You used "of course", which makes it sound as if it's "natural" to you to 
have revdep-rebuild want to rebuild "lots and lots of stuff".  I can 
assure you that's NOT the case here, and I don't believe it should EVER 
be the NORMAL case on a well maintained Gentoo system.  Once in a very 
long time, there may be individual upgrade cases where it happens because 
half the system depends on the upgraded library and the upgrade changed 
the ABI, the upgrade to expat-2 I believe it was comes to mind, but once 
that rebuild is done (and I'd say two weeks is plenty of time for that), 
it should be months, likely years, before any more more than perhaps a 
half dozen to a dozen packages (max) ever appear together at once on a 
revdep-rebuild.  I think it has been since that expat upgrade that I've 
ever had a half dozen items listed at once in revdep-rebuild here, and I 
even doubled that above, to a dozen, for those that run a bit sloppier 
installation than I.

I'd recommend that people do a world upgrade every couple of weeks 
minimum (noting that if you do it every week or every few days, you'll 
have less to upgrade all at once), always do an etc-update (or equivalent 
if using a different tool) after merging anything, just to be sure, and 
do a revdep-rebuild also at least every couple weeks, again noting that 
doing it more often means less stuff at once to worry about.  That, plus 
a regular (say once a month or so minimum) emerge --newuse, revdep-
rebuild, emerge --depclean, and another revdep-rebuild just to be sure 
after the depclean, will help keep the system clean and well maintained, 
and that "Of course revdep-rebuild wants to rebuild lots and lots of 
stuff" problem should become a thing of the past. =8^)

Of course, don't forget the --pretend first, especially on --depclean, 
but really on all the above, so you have some idea of what it's going to 
do and can add packages to your world file or whatever if necessary.  And 
again, those are what I'd recommend as minimums.  Remember that if you do 
it more frequently, you have far less to deal with at once, making the 
job far easier. =8^)  

It's just that "revdep rebuild wants to rebuild lots and lots of stuff" 
should be a very unusual event, not EVER an "of course" event  If that's 
NOT the case, if it HAS become an "of course" event, it's simply because 
someone has been slacking.  While it'll only mean minor stuff broken on a 
day to day basis, sooner or later it'll catch up to you, either with a 
compound failure so large it's difficult to recover from (a broken gcc 
making it impossible to recompile anything to fix it, for instance, or a 
broken python making it impossible to emerge anything), or with an old 
and stale package you've forgotten about getting a security vuln that 
someone takes advantage of, and you get cracked.

(Yeah, I know that some folks don't upgrade for six months or more at a 
time...  I never really understood why these folks bother to run Gentoo, 
as at that point, it's likely going to be easier doing the binary 
distribution update thing, with upgrades coming out about every six 
months, than trying to do an upgrade a piece at a time on Gentoo, without 
breaking anything vital in the process.  Yes, it's possible to do six 
month upgrades on Gentoo, just like it's possible to only install the 
binary packages on the release and package media and never compile 
anything, but it's really not /designed/ for that, and there are other 
distributions that handle those usage cases rather better, so Gentoo's a 
rather poor choice for them.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list



  reply	other threads:[~2008-03-25  3:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-24 23:25 [gentoo-amd64] CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed" Mark Knecht
2008-03-25  1:22 ` [gentoo-amd64] " Mark Knecht
2008-03-25  3:52   ` Duncan [this message]
2008-03-25  4:45     ` Mark Knecht
2008-03-25 11:05       ` Duncan
2008-03-25 11:16         ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pan.2008.03.25.03.52.47@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-amd64@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox