From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Pmdqw-00079E-8j for garchives@archives.gentoo.org; Tue, 08 Feb 2011 03:02:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2CED2E0A94 for ; Tue, 8 Feb 2011 03:02:52 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by pigeon.gentoo.org (Postfix) with ESMTP id D9375E094E for ; Tue, 8 Feb 2011 02:45:37 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PmdaC-0004Gx-Co for gentoo-amd64@lists.gentoo.org; Tue, 08 Feb 2011 03:45:36 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Feb 2011 03:45:36 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Feb 2011 03:45:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Major update problem Date: Tue, 8 Feb 2011 02:45:24 +0000 (UTC) Message-ID: References: <201102071227.16730.gentoo@appjaws.plus.com> <201102071327.06792.gentoo@appjaws.plus.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies; GIT 25ed40d branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: eb58e0da1d1e27b8ab94822cc4078b86 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 t= o >> intel quad. >> All seems to be working well except my previous post ref eth3.=20 >> 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) >>=20 >> I seem to have the current kde 4.5.5 required by @selected e.g. >>=20 >> (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 >>=20 >> 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= =20 new to the 2.1 series... new enough this is the first I'd heard of sets=20 support being unmasked to ~arch (I've been running the masked 2.2 series)= ,=20 tho I've not synced since Feb 4. You'll want to read up on sets support. In short, the @ prefix indicates= =20 a set, with @system and @world special-cased for backward compatibility t= o=20 be usable without the @ (so as simply system and world, the way it has=20 worked for years) as well. @selected is /just/ the stuff in world,=20 excluding system, while @world continues to include @system as well, just= =20 like it always did before the @ notation. What sets makes possible, tho, is essentially, subsets of the world file=20 treated as a single unit, aka "set". An example of how it can be used ar= e=20 the kde sets, long kept in the overlay until an unmasked portage with set= s=20 support hit the tree (sets support was masked for quite some time due to=20 controversy over the exact format, as paludis apparently implemented sets= =20 first and a bit differently), but, now with an at least ~arch portage wit= h=20 sets, presumably the kde sets will be (are? as I said I've not synced in = a=20 few days) in-tree as well, and one could emerge @kdebase, for instance, t= o=20 get the whole set of packages found in the kdebase monolithic tarball fro= m=20 upstream. Or take this as a sysadmin example: I have no world file at all. =20 Instead, portage tracks the sets I have installed in the world_sets file,= =20 and I edit individual sets by function, kept in /etc/portage/sets,=20 instead. Here's my listing. (JED are my initials, used here to ensure=20 that any sets I create manually don't get confused with possible tree=20 sets. My kde sets are similar to the ones from the overlay, but with a=20 few packages commented as unneeded, so they don't get installed.) The=20 contents of a couple of the sets files follow, as examples: $>>cat /var/lib/portage/world_sets=20 @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=20 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=20 #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=20 my worldfile. Put all the worldfile packages in sets, list them in the=20 world_sets file, and the worldfile itself can be emptied! =3D:^) Note the comment hashes in that last one. Every time kde 4.x bumps (so=20 4.5 to 4.6, but not 4.5.4 to 4.5.5, for example), I diff my jed.kde.*=20 files against the ones (that were) in the overlay, seeing what got added=20 or removed, and doing the same to my sets. Thus, I comment lines for=20 packages I don't want to install, instead of removing them, so the side-b= y- side diffs line up better and it's easier to see what changed between the= =20 two versions. As I said, I don't (normally) have anything in my world file at all --=20 it's now all in the individual sets I've setup. I set it up this way whe= n=20 I was setting up my netbook, a bit over a year ago (sets have been=20 available in the 2.2 series that long), as sorting my (previous) world=20 file into sets based on functional categories, and then going thru each=20 one to see what changes I wanted to make to that category as opposed to=20 the list on my workstation, was far easier than trying to tackle the=20 original huge world file in one go. However, now that I have it setup that way, I do use the world file as a=20 sort of "package purgatory", when I'm testing something new. My default=20 emerge scripts always use -1, so the package isn't added to my world file= =20 immediately. I can then test the package a bit and if I'm sure I want to= =20 keep it, I add it to the appropriate set. If however I want to test it a= =20 bit more, I add it to the world file instead. That way, portage knows I=20 want to track upgrades if they appear, and won't remove the package when = I=20 --depclean (which I do after every update session, keeping the cruft from= =20 building up), but the package is still in the "purgatory" of the world=20 file, so I know it's still in testing. After a few days or weeks, I'll=20 then either emerge -C the package, thus removing it from the world file,=20 or move the entry to the appropriate set, depending on whether I've=20 decided to keep the package permanently or not. > Sorry to reply to my own post but it seems that my world file had all o= f > the kde programs listed with ":4.5" > I don't know how this has happened but I removed the :4.5 from the line= s > and now if I run an emerge I get the following:- >=20 > Total: 268 packages (24 upgrades, 12 new, 228 in new slots, 4 > reinstalls, 230 uninstalls), Size of downloads: 424,321 kB > Conflict: 459 blocks >=20 > Would you like to merge these packages? [Yes/No] >=20 > Why would 228 packages be installed in new slots? Gentoo/kde (which is where most of those 228 new-slots are, if you look)=20 uses the slots for (at least) two reasons. First, there's the (unsupported and normally use.masked, but used for=20 testing) kdeprefix USE flag, which allows multiple slots to be installed=20 at the same time, thus allowing testing of unstable versions while the=20 stable version remains actually installed and used for normal tasks. The= =20 reason this is unsupported is that there's a number of complications and=20 breakages introduced by this flag, as kde4 really isn't designed to work=20 this way. The problems can normally be worked around, but the hassle and= =20 technical knowledge level for doing so is such that they don't support it= =20 for normal users, thus the flag is use.masked and unmasking/activating it= =20 unsupported, but it remains available for those, primarily gentoo/kde dev= s=20 using it as I said for testing, that want to risk it and can tolerate a=20 bit of breakage and hassle in ordered to do so. Second, slot-specified dependencies vastly simplify things, as it's then=20 possible to depend on, for example, kdelibs:4.6 instead of specifying all= =20 the individual 4.6 versions (including 4.5.98, etc, prereleases, in the=20 4.6 slot but that =3Dkdelibs-4.6* wouldn't work with). Complicating things especially for the listing is that the various slots=20 generally block each other, as well, tho as explained above, unmasking an= d=20 setting USE=3Dkdeprefix would eliminate most of the blockages... at the=20 expense of various other breakages, thus the use.mask and blockages in th= e=20 first place. Granted, hundreds of package-blocks looks overwhelming at first, but once= =20 you understand what's actually happening and why, fortunately, it's=20 generally much simpler to fix than all those hundreds of blocks would see= m=20 to suggest at first glance. In your case, it was a simple matter of=20 removing those slot-specifiers in your world file. =3D:^) --=20 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