Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted.
Date: Thu, 09 Dec 2010 12:03:23
In Reply to: Re: [gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted. by Dale
1 Dale posted on Thu, 09 Dec 2010 00:11:20 -0600 as excerpted:
3 >> $ eselect profile list
4 >> Available profile symlink targets:
5 >> [1] default/linux/amd64/10.0
6 >> [2] default/linux/amd64/10.0/desktop
7 >> [3] default/linux/amd64/10.0/desktop/gnome
8 >> [4] default/linux/amd64/10.0/desktop/kde
9 >> [5] default/linux/amd64/10.0/developer
10 >> [6] default/linux/amd64/10.0/no-multilib *
11 >> [7] default/linux/amd64/10.0/server
12 >> [8] hardened/linux/amd64
13 >> [9] hardened/linux/amd64/no-multilib
14 >> [10] selinux/2007.0/amd64
15 >> [11] selinux/2007.0/amd64/hardened
16 >> [12] selinux/v2refpolicy/amd64
17 >> [13] selinux/v2refpolicy/amd64/desktop
18 >> [14] selinux/v2refpolicy/amd64/developer
19 >> [15] selinux/v2refpolicy/amd64/hardened
20 >> [16] selinux/v2refpolicy/amd64/server
21 >> $
22 >>
23 >>
24 >>
25 > I read the whole post and it explained a lot. I think you read my mind
26 > and posted the list of profiles available too. I asked for that in
27 > another reply and when I hit send, I saw your replies. There was the
28 > list of profiles. You got ESP or do us Gentooers think alike? lol
30 =:^)
32 > I'm liking the option you are using. It seems clean and simple. Is #4
33 > no-multilib or multilib? I suspect it is multi. I ask because as you
34 > already know I use KDE and I also use the kde profile in x86. The stuff
35 > 8 and below are way over my head. I'm not even thinking of going into
36 > that area. ;-)
38 Yeah, hardened/selinux are rather different, and not something I've gotten
39 into either.
41 #4 (the kde profile) is indeed multilib, as is the general desktop profile
42 (#2). However, the difference other than multilib/no-multilib specifics
43 is simply that a number of USE flags are turned on by default in those
44 profiles. So if you either have gotten your set of USE flags pretty well
45 specified in make.conf regardless of the defaults already, or know what
46 you want well enough to scan USE flags as you build the system and set
47 them accordingly, that's not a big deal.
49 In fact, presuming that in general you want the same sort of USE flags you
50 have now, what you might wish to do is run an emerge --info, and compare
51 the USE flags it spits out with what's in your make.conf, adding what's
52 missing there. (You might want to run an emerge -N @world then, and
53 resolve any differences, which presuming you do that routinely already,
54 would be only those packages that have USE defaults that are now contrary
55 to your new specific flags.) Then you can pretty much simply copy those
56 USE flags over to the new system when you're setting it up, and I believe
57 it'll complain then (next emerge) about anything that's masked in your new
58 amd64 profile, so you can resolve it.
60 Actually, that's pretty close to what I did only going the other way, when
61 I built my 32-bit chroot image for my netbook. I pretty much copied all
62 my portage settings over, making changes where I needed to, and let it go
63 to work. Obviously I needed to change C(XX)FLAGS, ACCEPT_KEYWORDS, CHOST,
64 and a couple of the filesystem paths, but pretty much everything else,
65 definitely including USE flags, stayed pretty much as it was. (I think I
66 changed a couple USE flags I decided I didn't need on the netbook, and
67 obviously, I changed some of the use-expand vars like VIDEO_CARDS, etc, to
68 match the new hardware.)
70 I don't know what portage you're using, but I'm using the (still masked)
71 2.2.0_alphaX series in ordered to have set support, as I used that
72 originally for kde4. However, as I was setting up my 32-bit chroot, I
73 decided it would be easiest to categorize and split up my world file into
74 several purpose-descriptive sets, as I already had kde split up.
76 Thus I now have (jed is my initials, I use them so if I copy sets from
77 elsewhere, I know which I've customized and which not, obviously they're
78 all customized now):
80 $ cat /var/lib/portage/world_sets
81 @jed.admin
84 @jed.fonts
85 @jed.kde.base.kdeartwork
86 @jed.kde.base.kdebase.apps
87 @jed.kde.base.kdebase.runtime
88 @jed.kde.base.kdebase.workspace
89 @jed.kde.base.kdegames
90 @jed.kde.base.kdegraphics
91 @jed.kde.base.kdemultimedia
92 @jed.kde.base.kdeoptional
93 @jed.kde.base.kdepim
94 @jed.kde.base.kdetoys
95 @jed.kde.base.kdeutils
96 @jed.kde.misc
97 @jed.kde.plasmoids
99 @jed.misc
101 @jed.portage
102 @jed.utils
103 @jed.xorg
104 $
106 My world file itself is entirely empty, as I've categorized everything
107 into those sets.
109 Sorting everything into sets like that made it far easier to copy them
110 over for the new machine, then go thru each one, one at a time, and decide
111 which packages I wanted on the new machine and which I didn't need. I now
112 edit the appropriate set instead of adding things to my world file.
114 (More precisely, I have portage set to use --oneshot by default, so it
115 doesn't add them automatically. If I want to test something for a short
116 period, I can thus simply emerge it, and it'll be listed in the next
117 emerge -a --depclean I run, routinely after every upgrade, as a reminder
118 that it's not permanent yet and wasn't automatically checked for upgrades
119 as it's not in the world file. If I then decide it's worth testing some
120 more, I use emerge --noreplace, to add it to the world file but not to
121 sets. Then I check the world file periodically and either move entries to
122 the appropriate set or delete them, depending on whether I've decided that
123 package is worth keeping around or not. But as I like to keep things
124 clean, having something stuck in world instead of in a set bothers me, and
125 nothing stays there for long, so the world file itself /is/ usually
126 entirely empty. And my world file /is/ empty ATM as it usually is, so the
127 above statement is correct.)
129 So if you're using a portage with set support already, consider doing
130 likewise. If the list is ultimately going to be nearly the same anyway,
131 handling it that way sure beats merging only what you remember now, and
132 having to merge additional packages as you miss them as time goes on. It
133 also sure beats trying to wade thru an unsorted world file! =:^)
135 > I do have nvidia video cards. I assume the nvidia-drivers package will
136 > work fine with no-multilib? The way I am reading things it will but I
137 > do want drivers that work.
139 Again I'm not really the one to ask on that as it's servantware, but
140 AFAIK, it does. It just compiles only the 64-bit stuff if you don't have
141 multilib, where the 32-bit stuff is only to support 32-bit only apps,
142 primarily games, so if you're already considering no-multilib as you don't
143 have 32-bit-only software (including games) to worry about, then you
144 shouldn't miss the 32-bit stuff the nvidia driver would compile either.
146 Meanwhile, /have/ you tried the nouveau drivers recently, with a new
147 kernel (the newer the better, 2.6.36 or 2.6.37-rc) and new mesa (7.9's
148 good) and xorg-server (1.9.2)? I imagine the servantware drivers will
149 remain best for folks doing games for some time, but if you're not
150 particularly into gaming, as it sounds like may be the case, and
151 especially for older hardware that nVidia's not supporting in the current
152 drivers anyway, how well /is/ nouveau doing? I ask because I really don't
153 know, but surely, at some point, it's gotta get good enough at least for
154 non-gamers to be worth considering instead of the hassle of having to
155 rebuild the servantware drivers every time you update the kernel. But I
156 don't know. Does it support twinview and all that yet?
158 If you or anyone else have tried it recently, I'd /love/ to know how
159 well... or poorly as the case may be... it's doing these days, at least
160 for basic kde desktop effects accel, etc. And since I already know you're
161 a Gentoo AND a KDE user, and that you do tend to run pretty fresh kde...
162 if I remember correctly, well newer that what's unmasked to stable... now
163 that I know you have the hardware to try it with, as well...
165 --
166 Duncan - List replies preferred. No HTML msgs.
167 "Every nonfree program has a lord, a master --
168 and if you use the program, he is your master." Richard Stallman