Rev | Author | # | Line |
---|---|---|---|
11 | ChetanSarva | 1 | !!! Sundry helpful trivia |
2 | |||
3 | * To be able to su(1), you must be in group <tt>wheel</tt>: <tt>usermod -G wheel user</tt> | ||
4 | * To be able to use the SoundCard, you must be in group <tt>audio</tt>: <tt>usermod -G audio user</tt> | ||
5 | * There is a thread in the Gentoo about [Non-standard Portage Utilities | http://forums.gentoo.org/viewtopic.php?t=67849] | ||
15 | JohnMcPherson | 6 | |
7 | !!!Package querying basics | ||
8 | !Searching available package names | ||
9 | emerge search ''part of packagename'' | ||
10 | |||
11 | !Listing files in a package | ||
12 | (old way) | ||
13 | qpkg -l ''packagename'' | ||
14 | (newer way) | ||
15 | equery f ''packagename'' | ||
16 | |||
11 | ChetanSarva | 17 | |
18 | !!! Changing <tt>USE</tt> flags | ||
19 | |||
20 | If you've added (or removed) some <tt>USE</tt> flags on your system, there will be some inconsistencies with how some packages are compiled. | ||
21 | |||
22 | To check the <tt>USE</tt> flags a particular package will make use of, and which it is actually compiled with, run the following: | ||
23 | <verbatim> | ||
24 | equery uses packagename | ||
25 | </verbatim> | ||
26 | |||
27 | If you'd like to check which packages will make use of a particular <tt>USE</tt> flag, do the following: | ||
28 | <verbatim> | ||
29 | equery hasuse useflag | ||
30 | </verbatim> | ||
31 | |||
32 | eg, to check which (installed) packages will make use of the 'ldap' flag, run: | ||
33 | <verbatim> | ||
34 | equery hasuse ldap | ||
35 | [ Searching for USE flag ldap in all categories among: ] | ||
36 | * installed packages | ||
37 | [I--] [ ] app-crypt/gnupg-1.2.6 (0) | ||
38 | [I--] [ ] dev-libs/cyrus-sasl-2.1.20 (2) | ||
39 | [I--] [ ] dev-php/php-4.3.10 (0) | ||
40 | [I--] [ ] kde-base/kdebase-3.3.2-r1 (3.3) | ||
41 | [I--] [ ] kde-base/kdelibs-3.3.2-r2 (3.3) | ||
42 | [I--] [ ] mail-client/evolution-1.4.6 (0) | ||
43 | [I--] [ ] mail-client/pine-4.61-r2 (0) | ||
44 | [I--] [ ] net-fs/samba-3.0.9-r1 (0) | ||
45 | [I--] [ ] net-misc/openssh-3.9_p1-r1 (0) | ||
46 | [I--] [ ] net-www/mozilla-firefox-1.0 (0) | ||
47 | [I--] [ ] net-www/mozilla-1.7.5 (0) | ||
48 | </verbatim> | ||
49 | |||
50 | If you make major changes to your <tt>USE</tt> flags, and want to rebuild your entire system to make use of this, you can either run | ||
51 | |||
52 | <verbatim> | ||
53 | emerge --emptytree world | ||
54 | </verbatim> | ||
55 | |||
56 | This will, however, rebuild *everything*. If you've changed your <tt>CFLAGS</tt> then that might make sense, but if you've only changed some <tt>USE</tt> flags and want to rebuild everything that might make use of it, try the following instead: | ||
57 | |||
58 | <verbatim> | ||
59 | emerge --newuse world | ||
60 | </verbatim> | ||
61 | |||
62 | This will only rebuild packages whose <tt>USE</tt> flags would change | ||
63 | |||
64 | !!! An <tt>emerge</tt> clobbered something vital, but I didn't see what! | ||
65 | |||
17 | DanielLawson | 66 | This happens a lot. If you run <tt>emerge -Du world</tt>, and don't have a tediously slow machine, chances are pretty good that at some point you'll emerge a package which will "automatically" overwrite some config option. It'll tell you about it, but you probably won't be watching. The <tt>shadow</tt> package was doing this for a while, and was overwriting the [PAM] configuration -- screwing anyone who used any non-standard [PAM] options. |
11 | ChetanSarva | 67 | |
17 | DanielLawson | 68 | * Don't emerge lots of packages at once. And make sure you read the output. This isn't overly useful advice. |
69 | * Set the <tt>PORT_LOGDIR</tt> variable in <tt>/etc/make.conf</tt>, and read over the log files generated by each <tt>emerge</tt> process. Or better yet, grab [portlog-info|http://tdegreni.free.fr/gentoo/portlog-info] to parse the output and give you the bits you want. | ||
70 | * Grab [ehush | http://abeni.sf.net/ebuilds/ehush] and use it to emerge instead -- it suppresses the noise and only shows useful information / warning content. | ||
71 | |||
72 | The last two options are ok, however this should be part of portage, not an external script. There is a [bug filed against portage | http://bugs.gentoo.org/show_bug.cgi?id=11359] for this, but it's been about two years and nothing has actually happened. It's possible this will be included in the 'next version of portage', whenever that comes out. | ||
11 | ChetanSarva | 73 | |
74 | !!! <tt>USE</tt> flags for specific packages | ||
75 | |||
76 | You can set specific <tt>USE</tt> flags for a given package in the package attribute <tt>/etc/portage/package.use</tt>. Those flags will then be applied to that package as though they were specified on the CommandLine. Eg., to build BitTorrent without [X11] support: | ||
77 | |||
78 | <verbatim> | ||
79 | echo net-p2p/bittorrent -X >> /etc/portage/package.use | ||
80 | </verbatim> | ||
81 | |||
82 | !!! Masked Packages | ||
83 | |||
13 | NickJohnson | 84 | Packages can be flagged as masked for a number of reasons. Mostly they are masked because they might break something, or they WILL break something. These tend to be masked in <tt>/usr/portage/profiles/packages.mask</tt>, and you can either forcibly install the package (see later), or unmask the package by commenting out the line. Note that this file is rebuilt everytime you emerge sync. There is a packages.unmask file, which allows you to unmask packages that have been explicitly masked, but use this with care: The package was probably masked for a good reason. You can look in /usr/portage/profiles/package.mask to see what packages are masked and why, and copy the declaration to /etc/portage/packages.unmask to unmask it. |
11 | ChetanSarva | 85 | |
86 | The other reason packages can be masked is that they are in the 'unstable' branch of the gentoo tree. This is essentially the same as unstable in debian. Sometimes things will break, othertimes they'll be fine. You're on your own. | ||
87 | |||
88 | The only recommended way to install masked packages is to add to <tt>/etc/portage/package.keywords</tt> an entry for the package you want to build. Do __not__, whatever you do, emerge the <tt>.ebuild</tt> directly, or try to override <tt>ACCEPT_KEYWORDS</tt> on the CommandLine. Eg., if you want to emerge [XFce]4 from the unstable tree, do: | ||
89 | |||
90 | <verbatim> | ||
14 | JohnMcPherson | 91 | echo 'wm-x11/xfce4 ~x86' >> /etc/portage/package.keywords |
92 | echo '=wm-x11/xfce4-4.0.0 ~x86' >> /etc/portage/package.keywords # specific version of the package | ||
93 | echo '~wm-x11/xfce4-4.0.0 ~x86' >> /etc/portage/package.keywords # all revisions of a specific version | ||
11 | ChetanSarva | 94 | </verbatim> |
95 | |||
96 | !!! Useful utilities | ||
97 | |||
98 | * revdep-rebuild - checks for broken library dependancies and rebuilds | ||
99 | * equery - various queries you can do against the portage system, such as checking <tt>USE</tt> flag settings, dependancies and so on. | ||
17 | DanielLawson | 100 | * [enotice|http://dev.gentoo.org/~eldad/] - this little tool keeps track of important information and notices (einfo / ewarn) from ebuilds, and logs them away for you to inspect. Very useful for boxes that have a large number of updates, where important bits (like, "we're overwriting your PAM config, fix it up afterwards" might get lost). |
101 | * [distclean| http://www.stacken.kth.se/~foo/gentoo/]- removes old source files from /usr/portage/distfiles - ie, ones that aren't associated with currently installed packages. |
lib/plugin/WlugLicense.php (In template 'html'):99: Warning: Invalid argument supplied for foreach()
lib/plugin/WlugLicense.php (In template 'html'):111: Notice: Undefined variable: ignore_authors