[gentoo-amd64] Re: can't port to modular X

[Duncan]

Jürgen Schinker posted
<49586.10.10.10.10.1144392073.squirrel@×××××××××××××××××××.net>, excerpted
below,  on Fri, 07 Apr 2006 08:41:13 +0200:

> yeah i emerge xorg-x11 and it pulls font-adobe-75dpi and than stops with
> an error.....
>
> its hard to reproduce coz i have to uninstall xorg-6.8...
>
> every time and reinstall it so my system will be blocked a long time

It appears you may be unaware of one of my favorite not-well-enough-known
portage features.  Try reading up on portage FEATURES=buildpkg.  (There's
a bit on it in the Gentoo Handbook, and there's also info about it in the
make.conf manpage and in make.conf.example.  It's also googleable.)
 
Basically, what FEATURES=buildpkg does is tell portage to build a binary
package every time it merges something. It then actually does the merge to
the live system from the binary package, thereby testing the package it
just created so you know right away if it fails for whatever reason.

With this set, you'll eventually have binary packages for everything on
your system, and any upgrade will build a binary package for it as well. 
That way, if the upgrade doesn't go as expected, you can quickly remerge
the old version from its binary package (using emerge -K or -k, see man
emerge), without having to wait for it to recompile again.  Likewise, once
the initial merge of a package version is accomplished and the binary
package built, it's relatively easy to switch between the old and the new
version, by just merging the version you want using the -K switch so
portage uses the package rather than trying to remerge from source.

The space required to store one copy of all the binary packages for an
entire system will run 1-2 gig, typically.  Because you'll want to keep
old versions around until you know the new ones are working right, and to
prevent having to weed out the old ones too frequently, figure four gig or
so.

Alternatively, or to create a binpkg out of something already merged to
your system, there's the quickpkg tool.  For this situation, since you
won't have built xorg-6.8 with FEATURES=buildpkg yet, the binary won't be
available yet, so use quickpkg to create the binary package out of what's
already on your system.  That'll give you an xorg-6.8 binary package, so
you can unmerge it and try merging 7.0 again.  Once you've done your
troubleshooting, you can remerge 6.8 from the binary package you just
created, without waiting for it to recompile.  It's still a hassle, but
significantly /less/ of one than having to wait for 6.8 to complete a full
recompile cycle too!

...

FWIW, font-adobe-75dpi is pulled in as a dependency only because it's used
by one of the xconfig applets (I believe I got that from the changelog).
If you don't plan to run that, say you already have a working config, you
won't need that specific package. You'll likely want either that or the
100dpi version, but either will do and it's likely you could do without
both if necessary.

Still, without the specific error it's hard to say whether it's directly a
font-adobe-75dpi issue, which you can avoid by simply package.provided-ing
that package, or a problem with the font utils, as suggested by others, in
which case it's likely you'll have problems with other fonts as well, so
avoiding this package won't do any good even if it's /not/ specifically
needed other than for something you won't be running anyway.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list