|Subject:||[gentoo-amd64] Re: can't port to modular X|
|Date:||Fri, 07 Apr 2006 12:24:27|
|In Reply to:||Re: [gentoo-amd64] can't port to modular X by "Jürgen Schinker"
Jürgen Schinker posted <495188.8.131.52.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 timeIt 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 -- firstname.lastname@example.org mailing list