[gentoo-amd64] Re: Major update problem

[Duncan]

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

$>>ls -1 /etc/portage/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.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