I want to talk about updating in gentoo but first I want to talk about linuxs wikis first.
I like perusing wikis. I use gentoo’s linux wiki so often I’m obligated to return what I learn back to it. I also recently discovered the Arch Linux Wiki and check it out every so often. It’s one of better put together wikis in the linux sphere. The regular hodgepodge you can see in technological wikis typically mean you have to sort data, vary between a myriad of different versions, blah…. It’s the only wiki I know that a distro maintains, making it detailed and concise. The gentoo version in contrast is built entirely by enthusiasts, though it’s has no professional maintenance. The Gentoo Linux Wiki maintainer does a heck service to the community which is what wiki’s are all about. Service to the community. The affiliated (Arch’s) wiki main point of concern will obviously be denying the force of attractive bias. The suppose the whole issue I’m trying to create is how healthy is this to wiki’s. The whole “The neutrality of this article or section is disputed“ will not be seen here says difference to the whole philosophy of a wiki.
The Arch Linux Wiki talks about the differences between distros and Arch. If I ever tried a new distro is would be Arch. People have been talking about Arch lately in the Ubuntu Forums, and I am definitely interested. I never heard of the ability of pacman to compile and though I’m curious I think it probably shouldn’t be touted as a selling-point. So it is unlikely I’ll switch soon. But in my opinion this bias-en-wiki. As well as neutrality arguments that all wiki should have another disclaimer should state the sed area is written by a maintainer.
As this Arch Linux states working with Gentoo can be boon or bust. I find it more boon though but sometimes it isnt always that way. Like all package systems dependencies are pulled in sometimes when we need a package. Emerging though can sometimes pull in dependencies you don’t want. Its best not update all items if say you patched a certain version of a packages. Here’s little dirty way around it:
First mask the package: nano /etc/portage/package.mask
app-emmulations/wine
add the specific version in package.unmask
nano /etc/portage/package.unmask
=app-emulation/wine-0.9.37
There are exceptions, for example, corefonts, the Microsoft fonts, don’t particularly render well on my system but several different packages uses them as a dependency. Even if I first mask them the dependency appears to override it. This is true also for the adobe fonts, which need to have anti-aliasing support to be brought up to date. I don’t want either of them. So what I do (I have no choice but to emerge these fonts) is mask them and then unmask the version that was used, like above, then delete these fonts. Locate the folder in /usr/share/fonts/ and change into its directory. Remove all the fonts then rebuild the cache.
rm *
fc-cache -vf
Now the fonts will not intrude on the rest of the system.
