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
