Editing GentooTips - CaffeinatedWiki

When saving, enter the following:

            _____  ##   ##  _______   _____ 
           / ____| ##   ## (  ____ ) |_   _|
 ##  ##   | (___   ##   ## | (    )|   | |  
 ## ##     \___ \  ##   ## | (____)|   | |  
 ####      ____) | ##   ## |  _____)   |_|  
 ####     |_____/  ##   ## | (              
 ## ##              #####  | )              
 ##  ##                    |/

Visit Preferences to set your user name

Here are a few things that might help you if you're just starting out with GentooLinux.

First let's start with Portage, since it's the heart of Gentoo. Portage is ''very'' flexible, the downside of that being that it requires some configuration. You should definitely use the Gentoo installation guide when installing GentooLinux (it's very good, walks you through the whole thing), available at their [http://www.gentoo.org homepage], but here are some things that I've found make Portage a bit nicer:

=== CFLAGS variable ===
My {{CFLAGS}} (in {{/etc/make.conf}}) are:
<code>
CFLAGS="-march=athlon-mp -O2 -pipe"
</code>
Some people might suggest some crazy CFLAGS to you, stuff like {{-march=athlon -O3 -finline-functions -ffast-math -fomit-frame-pointer -blah -blah2 -blah}}. I tried some pretty crazy stuff like that for a while, following other peoples' suggestions, and found that it made things considerably less stable. I find that I can temporarily change my CFLAGS if I really want, if something is very performance critical. But, by keeping the overal system-wide CFLAGS more modest, I gain a lot in stability. And, the CFLAGS I've given above are still pretty decent; more than binary distros will give you out of the box, to be sure. Adding {{-fomit-frame-pointer}} to the above is probably safe and could give you some more performance.

=== USE variable ===
My {{USE}} variable (also in {{/etc/make.conf}}) is:
<code>
USE="X dri xosd gnome gtk2 opengl xft2 freetype smooth firefox bmp aac flac mp3 ogg vorbis oggvorbis theora speex win32codecs avi divx4linux \
alsa apache2 gd dba session samba cups imap ldap ssl icq msn jabber nptl mmx sse acpi dvi t1lib cdr dvd dvdr dvdread spell ipod dbus hal \
-kde -qt -qtmt -qt3 -qt4 -arts -apm"
</code>
I don't use KDE, and I don't really want any KDE libs on my system, (heheh, see KdeVsGnome for ''that'' whole issue) hence the {{-kde -qt -qtmt -arts}}. So those (basically all the "-" ones) you may want to change. All the "positive" ones I think are pretty good, and I would highly recommend. "smooth" enables some tweaks to freetype to do better hinting, and fonts look great with that. The rest should be fairly self-explanatory.

Sometimes you may want a specific USE item for only a few packages, or you may wish to exclude a global USE item from some packages. For that, use {{/etc/portage/package.use}}. For example, you could add {{dev-java/sun-jdk -doc}} to {{/etc/portage/package.use}} to indicate that you do ''not'' want all the docs for Java installed. To add a use flag, do the same except omit the "-".

=== Package masking ===
{{/usr/portage/profiles/package.mask}}: this file contains a list of "masked" packages. Packages are "masked" in Gentoo when they're considered too unstable. Sometimes, however, you might want to "unmask" something (by adding it to {{/etc/portage/package.unmask}}).

=== World updates ===
Updating your system all at once: {{emerge sync}} followed by {{emerge -u world}} is a good way to do this. Some people might suggest using {{--deep}}. It can be useful, but I find that it's not something you really need to do all ''that'' often. Maybe once every few months or something. And, before using any of these, use {{-p}}, eg. {{emerge -up world}}. In fact, I also do an {{emerge -up world}} to see if anything would be downgraded (other than stuff I intentionally want to keep). Sometimes bugs are found in packages and they're temporarily "re-masked" while things are worked out a bit, and Portage will downgrade them for you. This is usually a good idea, but if you've been using things without any trouble you may want to keep the newer version.

=== ~arch? eh? ===
The whole {{~arch}} thing: in {{make.conf}}, there's an {{ACCEPT_KEYWORDS}} variable. If you set this to {{~arch}}, i.e. {{~x86}} for PCs, or {{~ppc}} for Macs or what have you, you will be using "development" versions of software. It used to be pretty reasonable to run with {{~arch}} turned on for everything, but these days that just requires way too much updating; around 50 or so packages a day on a typical system. So instead, you can specify packages for which you'd like the latest-and-greatest development version by adding the package name, followed by the keyword (eg. {{media-video/totem ~x86}}) to {{/etc/portage/package.keywords}}.

=== etc-update ===
This is actually pretty cool, although you might think it sucks after you do it a few times. What's going on is this: a lot of programs have system-wide config files, somewhere in {{/etc}}. When you update a package that has a config file in {{/etc}} (or in a few other locations, actually), emerge tells you that you need to update some config files. You can run a command called {{etc-update}} to help you with this, but I actually usually do it manually, because it isn't that hard, and there are some pretty good rules of thumb. Here's how I do it:

* I run {{find /etc |grep _cfg}}. This gives me a list of all the new config files that programs I updated wanted to install. When you update a program with a system-wide config file, the new config file that came with that program is named {{._cfg0000_filename}}, where {{filename}} is the original filename. This is done so that config files aren't automatically overwritten, a nice precaution. If the numbers aren't all 0s, that means you've been naughty and neglected to update the config file previously. Anyway, I then go through this list and diff the old config files with the new ones (see {{man diff}} if you don't know how to do this). I always do this, but it isn't always strictly necessary, due to this rule of thumb:
** If you've never modified the original config file, and always used the default, you can probably just move the new one overtop of it (eg. {{mv ._cfg0000_filename filename}}). I always diff anyway, but if you want to be lazy about it, you probably won't screw yourself over too badly.
** If you have modified the original, you should diff the two and merge your changes into the new one. This is usually pretty simple; it usually means just modifying a few lines of the form {{parameter = value}} or maybe uncommenting a few lines in the file to override default values. I mean, presumably if you made the changes in the first place you should know what they are!

=== rc-update ===
{{rc-update}} is pretty decent, you can think of it like RedHat's {{chkconfig}} or Debian's {{update-rc.d}}. Except that Gentoo doesn't have the same kinds of runlevels as RedHat or Debian do. Gentoo has runlevels called things like "default" or "nonetwork" or "reboot", which are a bit more intuitive than 3, 2 and 6, respectively. A big advantage of this is that when you use {{rc-update}}, the command you type will actually make a lot of sense, eg. {{rc-update add foobar default}} adds service {{foobar}} to the "default" runlevel, which is the one you usually use. I gotta say, I like that a bit better than the numerical system used by other distros, although it's nothing really earth shattering. I will stop to say that Debian's {{update-rc.d}} command sucks donkey brains through a straw, however. Its syntax is just a pain compared to {{rc-update}} or {{chkconfig}}. Meh, whatever. These ''are'' the people who use {{dselect}} =)

Summary of change:
Add document to category: