Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Major update problem
Date: Tue, 08 Feb 2011 03:02:54
In Reply to: Re: [gentoo-amd64] Major update problem by Paul Stear
Paul Stear posted on Mon, 07 Feb 2011 13:27:06 +0000 as excerpted:

> On Monday 07 February 2011 12:27:16 Paul Stear wrote: >> Hi, >> I am now using a new motherboard and processor - change from amd duo to >> intel quad. >> All seems to be working well except my previous post ref eth3. >> However, I am having problems updating my programs. >> eix-sync went well and portage updated to >> I then do an emerge -auvtDN --keep-going world and I get hundreds of >> blocked packages for kde e.g. >> [blocks B ] kde-base/kwrite:4.5[-kdeprefix] ("kde-base/kwrite:4.5[- >> kdeprefix]" is blocking kde-base/kwrite-4.6.0) >> >> I seem to have the current kde 4.5.5 required by @selected e.g. >> >> (kde-base/kdebase-meta-4.5.5, installed) pulled in by >> kde-base/kdebase-meta required by @selected >> kde-base/kdebase-meta:4.5 required by @selected >> >> What is @selected, I have never heard of this before, do I need to >> change something? I can't seem to find this referenced in any >> documentation.
The portage 2.2 series has had sets support for quite some time, but it's new to the 2.1 series... new enough this is the first I'd heard of sets support being unmasked to ~arch (I've been running the masked 2.2 series), tho I've not synced since Feb 4. You'll want to read up on sets support. In short, the @ prefix indicates a set, with @system and @world special-cased for backward compatibility to be usable without the @ (so as simply system and world, the way it has worked for years) as well. @selected is /just/ the stuff in world, excluding system, while @world continues to include @system as well, just like it always did before the @ notation. What sets makes possible, tho, is essentially, subsets of the world file treated as a single unit, aka "set". An example of how it can be used are the kde sets, long kept in the overlay until an unmasked portage with sets support hit the tree (sets support was masked for quite some time due to controversy over the exact format, as paludis apparently implemented sets first and a bit differently), but, now with an at least ~arch portage with sets, presumably the kde sets will be (are? as I said I've not synced in a few days) in-tree as well, and one could emerge @kdebase, for instance, to get the whole set of packages found in the kdebase monolithic tarball from upstream. Or take this as a sysadmin example: I have no world file at all. Instead, portage tracks the sets I have installed in the world_sets file, and I edit individual sets by function, kept in /etc/portage/sets, instead. Here's my listing. (JED are my initials, used here to ensure that any sets I create manually don't get confused with possible tree sets. My kde sets are similar to the ones from the overlay, but with a few packages commented as unneeded, so they don't get installed.) The contents of a couple of the sets files follow, as examples: $>>cat /var/lib/portage/world_sets @jed.admin @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.misc @jed.portage @jed.utils @jed.xorg $>>ls -1 /etc/portage/sets jed.admin 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.misc jed.portage jed.qt4.4.7.0 jed.qt4.4.7.1 jed.qt4.main jed.utils jed.xorg $>>cat /etc/portage/sets/jed.xorg media-video/xvattr x11-apps/mesa-progs x11-apps/xdpyinfo x11-apps/xev x11-apps/xfontsel x11-apps/xkill x11-apps/xmodmap x11-apps/xvidtune x11-apps/xwininfo x11-base/xorg-server x11-misc/sux x11-themes/gentoo-xcursors x11-themes/xcursor-themes $>>cat /etc/portage/sets/jed.kde.base.kdeoptional #kde-base/kdelirc kde-base/kfloppy #kde-base/kppp #kde-base/policykit-kde $>> See? Each set is basically a subset of the much longer list formerly in my worldfile. Put all the worldfile packages in sets, list them in the world_sets file, and the worldfile itself can be emptied! =:^) Note the comment hashes in that last one. Every time kde 4.x bumps (so 4.5 to 4.6, but not 4.5.4 to 4.5.5, for example), I diff my jed.kde.* files against the ones (that were) in the overlay, seeing what got added or removed, and doing the same to my sets. Thus, I comment lines for packages I don't want to install, instead of removing them, so the side-by- side diffs line up better and it's easier to see what changed between the two versions. As I said, I don't (normally) have anything in my world file at all -- it's now all in the individual sets I've setup. I set it up this way when I was setting up my netbook, a bit over a year ago (sets have been available in the 2.2 series that long), as sorting my (previous) world file into sets based on functional categories, and then going thru each one to see what changes I wanted to make to that category as opposed to the list on my workstation, was far easier than trying to tackle the original huge world file in one go. However, now that I have it setup that way, I do use the world file as a sort of "package purgatory", when I'm testing something new. My default emerge scripts always use -1, so the package isn't added to my world file immediately. I can then test the package a bit and if I'm sure I want to keep it, I add it to the appropriate set. If however I want to test it a bit more, I add it to the world file instead. That way, portage knows I want to track upgrades if they appear, and won't remove the package when I --depclean (which I do after every update session, keeping the cruft from building up), but the package is still in the "purgatory" of the world file, so I know it's still in testing. After a few days or weeks, I'll then either emerge -C the package, thus removing it from the world file, or move the entry to the appropriate set, depending on whether I've decided to keep the package permanently or not.
> Sorry to reply to my own post but it seems that my world file had all of > the kde programs listed with ":4.5" > I don't know how this has happened but I removed the :4.5 from the lines > and now if I run an emerge I get the following:- > > Total: 268 packages (24 upgrades, 12 new, 228 in new slots, 4 > reinstalls, 230 uninstalls), Size of downloads: 424,321 kB > Conflict: 459 blocks > > Would you like to merge these packages? [Yes/No] > > Why would 228 packages be installed in new slots?
Gentoo/kde (which is where most of those 228 new-slots are, if you look) uses the slots for (at least) two reasons. First, there's the (unsupported and normally use.masked, but used for testing) kdeprefix USE flag, which allows multiple slots to be installed at the same time, thus allowing testing of unstable versions while the stable version remains actually installed and used for normal tasks. The reason this is unsupported is that there's a number of complications and breakages introduced by this flag, as kde4 really isn't designed to work this way. The problems can normally be worked around, but the hassle and technical knowledge level for doing so is such that they don't support it for normal users, thus the flag is use.masked and unmasking/activating it unsupported, but it remains available for those, primarily gentoo/kde devs using it as I said for testing, that want to risk it and can tolerate a bit of breakage and hassle in ordered to do so. Second, slot-specified dependencies vastly simplify things, as it's then possible to depend on, for example, kdelibs:4.6 instead of specifying all the individual 4.6 versions (including 4.5.98, etc, prereleases, in the 4.6 slot but that =kdelibs-4.6* wouldn't work with). Complicating things especially for the listing is that the various slots generally block each other, as well, tho as explained above, unmasking and setting USE=kdeprefix would eliminate most of the blockages... at the expense of various other breakages, thus the use.mask and blockages in the first place. Granted, hundreds of package-blocks looks overwhelming at first, but once you understand what's actually happening and why, fortunately, it's generally much simpler to fix than all those hundreds of blocks would seem to suggest at first glance. In your case, it was a simple matter of removing those slot-specifiers in your world file. =:^) -- 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


Subject Author
[gentoo-amd64] Re: Major update problem Jonathan Callen <abcd@g.o>