Re: [gentoo-user] --emptytree and slots
On Fri, Feb 13, 2009 at 8:34 AM, Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote: Hi, switching to a new machine is good opportunity to do house-cleaning. I wonder what emerge --emptytree does when several versions of some packages like kde or gcc are installed (in different slots). The entry in the 'world' file does not contain the slot info. Is there any danger it will leave my machine with only one version of each package? Many thanks for your help, Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany emerge -e world will re-emerge every package which is a dependency of packages in your world file. It won't, however, do housecleaning of packages in separate slots which are not used. To do that: #usually required to make the next step happy emerge -uDN world emerge -p --depclean Make sure you have the -p option, and sanity check the output of --depclean. It's almost always correct, but only almost. See man emerge for more information on other useful things the --depclean can do (in particular, it does what most people seem to think 'equery depends' does). Nick
Re: [gentoo-user] No /dev entries in recent stage3 snapshots?
On Tue, Jan 20, 2009 at 11:52 PM, Dirk Heinrichs dirk.heinrichs@nsn.com wrote: Am Mittwoch, den 21.01.2009, 04:04 + schrieb ext Grant Edwards: I'm a little confused. Is there supposed to be an additional installation step to populate the /dev directory when using recent stage3 snapshots? One usually bind-mounts /dev, /proc and /sys into the chroot, like mount --bind /dev /newinstall/dev # dito for /proc, /sys chroot /newinstall If this isn't documented, you should file a bug. HTH... Dirk The best gentoo chroot guide I know of is: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1chap=2 Obviously, throw out any 32-bit specific stuff if you aren't doing 32-bit on a 64-bit machine. Nick
Re: [gentoo-user] qt blockages...
On Tue, Jan 20, 2009 at 12:11 AM, KH gentoo-u...@konstantinhansen.dewrote: Daniel Pielmeier schrieb: 2009/1/19 KH gentoo-u...@konstantinhansen.de: This link was great help for me. Told me everything and how to read the blocker. So I did: #emerge -avC qt-4.3.3 #emerge -DuavN world (This installed qt-4.4.2) But now I do have a problem. When I run #emerge --depclean -av I receive the following output: [snip] These are the packages that would be unmerged: dev-db/sqlite selected: 2.8.16-r4 protected: none omitted: 3.6.6.2 x11-libs/qt selected: 4.4.2 protected: none omitted: 3.3.8b-r1 [snip some other qt-split-packages] What did I miss? This results in an infinite circle of unmerging and emerging. I don't think --with-bdeps will solve this issue as qt- packages are no build-time-dependencies they are needed at runtime too. Did the affected packages got installed by your previous emerge world command. My guess is that depclean wants to remove this packages because they are simply not needed by other packages. Did they really get pulled in when doing another world update after removing the packages? Maybe checking again your world file or the files in /etc/portage/package.* for something suspicious is a good idea here. Hi, yes I had the blocker when running emerge -DuavN world . I unmerged qt-4.3* and ran emerge -DuavN world again. That brought in the qt-4.4.2. Tho investigate further: equery d x11-libs/qt [ Searching for packages depending on x11-libs/qt... ] app-crypt/pinentry-0.7.5 (qt3? x11-libs/qt:3) app-text/poppler-bindings-0.8.7 (qt3? =x11-libs/qt-3.3:3) (qt4? =x11-libs/qt-4.3:4) media-video/vlc-0.9.8a (qt4? =x11-libs/qt-4.3*:4) (skins? =x11-libs/qt-4.3*:4) net-im/skype-2.0.0.63 (x86 !qt-static? =x11-libs/qt-4.3*:4) Those are still depending on qt-4.3* but non are depending on 4.4.2. I will try an emerge -1av skype to learn what it will depend on afterwards. kh You seem to have missed the point of this upgrade. The qt packages were split, as the single qt package was huge, without good reason. The ideal sequence of events (as I understand it) was: 1. qt-4.3.3 and split packages given mutual exclusion depends. 2. All packages depending on qt-4.3.3 get updated to having an || dependency between qt-4.3.3 and the correct split components. 3. split components stabilized, and qt-4.3.3 simultaneously masked (thus, no blockages, everyone upgrades) 4. qt-4.4.2 kept around for backward compatibility/badly formed e-builds, but is only a virtual package (check it out, it only has dependencies) Somehow, 2 didn't get finished, causing the masking in 3 to get dropped, hence the blocking. Nothing should ever need to depend on qt-4.4, as only needed components should be pulled in. Reference: http://bugs.gentoo.org/show_bug.cgi?id=248038 As has been pointed out, equery d is not a good indicator of dependency. Use emerge -pv --depclean atom for a real indication (equery does a grep of the ebuild file, emerge only reports active dependencies, which is what most people care about. I've been tempted to file a bug for a while, but this seems to be the accepted behavior). Nick
Re: [gentoo-user] qt blockages...
On Mon, Jan 19, 2009 at 2:37 PM, Mark Knecht markkne...@gmail.com wrote: On Mon, Jan 19, 2009 at 2:18 PM, KH gentoo-u...@konstantinhansen.de wrote: Mark Knecht schrieb: Hi, I'm not used to seeing all the additional messages below the blockage indication. Can someone possibly help me understand how to read this? Are there really application packages that cannot be installed at the same or is only about qt and possibly the USE flags I've got? I tried removing qjackctl (the only world package I spotted in the list) but that didn't help. What to try next? Thanks, Mark [snip] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked [snip] This link was great help for me. Told me everything and how to read the blocker. So I did: #emerge -avC qt-4.3.3 #emerge -DuavN world (This installed qt-4.4.2) But now I do have a problem. When I run #emerge --depclean -av I receive the following output: [snip] These are the packages that would be unmerged: dev-db/sqlite selected: 2.8.16-r4 protected: none omitted: 3.6.6.2 x11-libs/qt selected: 4.4.2 protected: none omitted: 3.3.8b-r1 x11-libs/qt-svg selected: 4.4.2 protected: none omitted: none x11-libs/qt-opengl selected: 4.4.2 protected: none omitted: none x11-libs/qt-xmlpatterns selected: 4.4.2 protected: none omitted: none x11-libs/qt-assistant selected: 4.4.2-r1 protected: none omitted: none x11-libs/qt-webkit selected: 4.4.2 protected: none omitted: none What did I miss? This results in an infinite circle of unmerging and emerging. Thanks for any help kh In your /etc/make.conf file do you have the following line? EMERGE_DEFAULT_OPTS=--with-bdeps y You can do this on the emerge command line if you choose. See man emerge for info on doing that. I *think* the standard answer about why this happens is that --depclean and a basic emerge don't search all the dependencies exactly the same. If you add the --with-bdeps y option then they do. Anyway, I don't seem to run into this much using this in make.conf. Hope this helps, Mark using --with-bdeps=y would certainly work (and in the interest of full disclosure is what I do), but it shouldn't be necessary. Having emerge --depclean remove build dependencies should be ok. Afterwards, emerge -avuDN world should do nothing, as although the build dependencies for packages are missing, the world packages themselves don't need rebuilding, so there is nothing to do. Thus, there is no infinite rebuilding cycle, independent of the with-bdeps flag. Nick
