[gentoo-amd64] Re: CUPS now failing with "/usr/libexec/cups/filter/foomatic-rip failed"

[Duncan]

"Mark Knecht" <markknecht@×××××.com> posted
5bdc1c8b0803242145le54b0c9we8ba99a79c5c9f9@××××××××××.com, excerpted
below, on  Mon, 24 Mar 2008 21:45:30 -0700:

> Well, my experience is a bit different than yours. I'm sure the way I
> maintain my systems, reading between your lines, is almost certainly
> more lax than you care for. I do an emerge -DuN system in general about
> once a week, but emerge -DuN world isn't going to happen any more often
> than once every 6-8 weeks here. I don't have time to deal with the
> issues that come up with all this stuff to do it more than maybe 5-6
> times per year. Even that often is pushing it, but it's about what I do.

Well, if you note, I didn't push the --deep (= -D).  That'll save you 
some, but at the expense of rather more pain (including a longer revdep-
rebuild list since you'll likely have every dependency on the library 
listed by then, instead of just a couple) when you /do/ eventually update 
those deep dependencies.

I'd say do the system once a week, do the world every couple weeks, 
always do a revdep-rebuild after the world and keep your --depclean up to 
date so the revdep-rebuild isn't rebuilding dependencies you don't even 
need any more, but don't worry too much about --deep, especially on 
primarily stable systems (like the myth boxes you mention).  

Also, there's certainly less reason to worry about updates on machines 
that don't do Internet and/or don't hold private data (as may be the case 
with some of your myth boxes) anyway.  Six weeks or two months is still 
pushing it and may lead to a lot of pain when you /do/ upgrade such 
internal boxes, but there's no urgency other than that.

> My experience with revdep-rebuild is that it wants to build some old
> things, but then these things have been removed from portage and it
> cannot, so I have to start looking for solutions. That requires reading
> and thinking so it gets put on the back burner.

That's really part of the pain of not upgrading frequently enough.  As 
such, it's avoidable.  Upgrade before something is removed, and you won't 
have that problem.  Of course, there's a trade-off here between --deep 
and this pain, as well.  If you don't use --deep, you'll encounter this 
problem relatively more frequently.  However, it's a trade-off that's up 
to you.

> The other reason I'll almost NEVER do a real emerge -DuN world is that
> we use MythTV here. We have 5 machines that run Myth, either as front
> ends or back ends. Unfortunately, with Myth if you update the server you
> have to update every machine on the network which causes problems for
> the family so I don't do it.

You have multiple machines.  Are you making use of binary packages?  
Assuming you use portage, FEATURES=buildpkg on your first upgraded 
machine, with all machines set to use the same PKGDIR and using emerge 
--usepkgonly (-K) on everything but the first one (at least where USE 
flags are the same, and assuming compatible machine and instruction 
types) should be a real boon to you.

IOW, if you are recompiling the package for each machine it's deployed 
on, you are wasting way more time and energy on that than you are saving 
by updating so infrequently.  If it's possible to do the build once and 
use it on multiple machines, it's very likely worth doing so, even if it 
means modifying USE flags and CFLAGS/CXXFLAGS a bit so you /can/ use a 
common binary.  That could just make the upgrades on those myth machines 
much less trouble for you.

Even if my "big" machine was amd64 and the others were x86, as just might 
be your case, I'd still consider FEATURES=buildpkg, and either decide to 
run the big machine at 32-bit, or run it 64-bit but with a 32-bit chroot, 
so it could still could build the binaries for the others.  (Of course, 
for same machine arch, you could also run distcc if desired, but that's 
getting to be less of an advantage as quad-core multi-gig memory machines 
work their way into the mainline.)

> revdep-rebuild today wanted to rebuild 16 apps. To me that's lots and
> lots. Maybe not to you.

Well, I'd call that "lots", but not "lots and lots". =8^)  "Lots and 
lots" would to me start at say a couple dozen, so 24, maybe 30.  
Certainly, a KDE upgrade, typically 90-120 packages on my machine, would 
qualify for three "lots", tho I'd more likely term it "a hundredish" 
packages.

Interesting how such words mean slightly different things to different 
people, isn't it?  =8^)

-- 
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@l.g.o mailing list