[gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted.

[Duncan]

Dale posted on Thu, 09 Dec 2010 00:11:20 -0600 as excerpted:

>> $ eselect profile list
>> Available profile symlink targets:
>>    [1]   default/linux/amd64/10.0
>>    [2]   default/linux/amd64/10.0/desktop
>>    [3]   default/linux/amd64/10.0/desktop/gnome
>>    [4]   default/linux/amd64/10.0/desktop/kde
>>    [5]   default/linux/amd64/10.0/developer
>>    [6]   default/linux/amd64/10.0/no-multilib *
>>    [7]   default/linux/amd64/10.0/server
>>    [8]   hardened/linux/amd64
>>    [9]   hardened/linux/amd64/no-multilib
>>    [10]  selinux/2007.0/amd64
>>    [11]  selinux/2007.0/amd64/hardened
>>    [12]  selinux/v2refpolicy/amd64
>>    [13]  selinux/v2refpolicy/amd64/desktop
>>    [14]  selinux/v2refpolicy/amd64/developer
>>    [15]  selinux/v2refpolicy/amd64/hardened
>>    [16]  selinux/v2refpolicy/amd64/server
>> $
>>
>>
>>
> I read the whole post and it explained a lot.  I think you read my mind
> and posted the list of profiles available too.  I asked for that in
> another reply and when I hit send, I saw your replies.  There was the
> list of profiles.  You got ESP or do us Gentooers think alike?  lol

=:^)

> I'm liking the option you are using.  It seems clean and simple.  Is #4
> no-multilib or multilib?  I suspect it is multi.  I ask because as you
> already know I use KDE and I also use the kde profile in x86.  The stuff
> 8 and below are way over my head.  I'm not even thinking of going into
> that area.  ;-)

Yeah, hardened/selinux are rather different, and not something I've gotten 
into either.

#4 (the kde profile) is indeed multilib, as is the general desktop profile 
(#2).  However, the difference other than multilib/no-multilib specifics 
is simply that a number of USE flags are turned on by default in those 
profiles.  So if you either have gotten your set of USE flags pretty well 
specified in make.conf regardless of the defaults already, or know what 
you want well enough to scan USE flags as you build the system and set 
them accordingly, that's not a big deal.

In fact, presuming that in general you want the same sort of USE flags you 
have now, what you might wish to do is run an emerge --info, and compare 
the USE flags it spits out with what's in your make.conf, adding what's 
missing there.  (You might want to run an emerge -N @world then, and 
resolve any differences, which presuming you do that routinely already, 
would be only those packages that have USE defaults that are now contrary 
to your new specific flags.)   Then you can pretty much simply copy those 
USE flags over to the new system when you're setting it up, and I believe 
it'll complain then (next emerge) about anything that's masked in your new 
amd64 profile, so you can resolve it.

Actually, that's pretty close to what I did only going the other way, when 
I built my 32-bit chroot image for my netbook.  I pretty much copied all 
my portage settings over, making changes where I needed to, and let it go 
to work.  Obviously I needed to change C(XX)FLAGS, ACCEPT_KEYWORDS, CHOST, 
and a couple of the filesystem paths, but pretty much everything else, 
definitely including USE flags, stayed pretty much as it was.  (I think I 
changed a couple USE flags I decided I didn't need on the netbook, and 
obviously, I changed some of the use-expand vars like VIDEO_CARDS, etc, to 
match the new hardware.)

I don't know what portage you're using, but I'm using the (still masked) 
2.2.0_alphaX series in ordered to have set support, as I used that 
originally for kde4.  However, as I was setting up my 32-bit chroot, I 
decided it would be easiest to categorize and split up my world file into 
several purpose-descriptive sets, as I already had kde split up.

Thus I now have (jed is my initials, I use them so if I copy sets from 
elsewhere, I know which I've customized and which not, obviously they're 
all customized now):

$ cat /var/lib/portage/world_sets 
@jed.admin
@jed.bible
@jed.dev
@jed.fonts
@jed.kde.base.kdeartwork
@jed.kde.base.kdebase.apps
@jed.kde.base.kdebase.runtime
@jed.kde.base.kdebase.workspace
@jed.kde.base.kdegames
@jed.kde.base.kdegraphics
@jed.kde.base.kdemultimedia
@jed.kde.base.kdeoptional
@jed.kde.base.kdepim
@jed.kde.base.kdetoys
@jed.kde.base.kdeutils
@jed.kde.misc
@jed.kde.plasmoids
@jed.media
@jed.misc
@jed.net
@jed.portage
@jed.utils
@jed.xorg
$ 

My world file itself is entirely empty, as I've categorized everything 
into those sets.

Sorting everything into sets like that made it far easier to copy them 
over for the new machine, then go thru each one, one at a time, and decide 
which packages I wanted on the new machine and which I didn't need.  I now 
edit the appropriate set instead of adding things to my world file.

(More precisely, I have portage set to use --oneshot by default, so it 
doesn't add them automatically.  If I want to test something for a short 
period, I can thus simply emerge it, and it'll be listed in the next 
emerge -a --depclean I run, routinely after every upgrade, as a reminder 
that it's not permanent yet and wasn't automatically checked for upgrades 
as it's not in the world file.  If I then decide it's worth testing some 
more, I use emerge --noreplace, to add it to the world file but not to 
sets.  Then I check the world file periodically and either move entries to 
the appropriate set or delete them, depending on whether I've decided that 
package is worth keeping around or not.  But as I like to keep things 
clean, having something stuck in world instead of in a set bothers me, and 
nothing stays there for long, so the world file itself /is/ usually 
entirely empty.  And my world file /is/ empty ATM as it usually is, so the 
above statement is correct.)

So if you're using a portage with set support already, consider doing 
likewise.  If the list is ultimately going to be nearly the same anyway, 
handling it that way sure beats merging only what you remember now, and 
having to merge additional packages as you miss them as time goes on.  It 
also sure beats trying to wade thru an unsorted world file! =:^)

> I do have nvidia video cards.  I assume the nvidia-drivers package will
> work fine with no-multilib?  The way I am reading things it will but I
> do want drivers that work.

Again I'm not really the one to ask on that as it's servantware, but 
AFAIK, it does.  It just compiles only the 64-bit stuff if you don't have 
multilib, where the 32-bit stuff is only to support 32-bit only apps, 
primarily games, so if you're already considering no-multilib as you don't 
have 32-bit-only software (including games) to worry about, then you 
shouldn't miss the 32-bit stuff the nvidia driver would compile either.

Meanwhile, /have/ you tried the nouveau drivers recently, with a new 
kernel (the newer the better, 2.6.36 or 2.6.37-rc) and new mesa (7.9's 
good) and xorg-server (1.9.2)?  I imagine the servantware drivers will 
remain best for folks doing games for some time, but if you're not 
particularly into gaming, as it sounds like may be the case, and 
especially for older hardware that nVidia's not supporting in the current 
drivers anyway, how well /is/ nouveau doing?  I ask because I really don't 
know, but surely, at some point, it's gotta get good enough at least for 
non-gamers to be worth considering instead of the hassle of having to 
rebuild the servantware drivers every time you update the kernel.  But I 
don't know.  Does it support twinview and all that yet?

If you or anyone else have tried it recently, I'd /love/ to know how 
well... or poorly as the case may be... it's doing these days, at least 
for basic kde desktop effects accel, etc.  And since I already know you're 
a Gentoo AND a KDE user, and that you do tend to run pretty fresh kde... 
if I remember correctly, well newer that what's unmasked to stable... now 
that I know you have the hardware to try it with, as well...

-- 
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