Summary: | profile handling when PORTDIR does not point to /usr/portage | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bill Skellenger <william> |
Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED INVALID | ||
Severity: | major | CC: | alonbl, printing |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | Potential portage issue? | ||
Package list: | Runtime testing required: | --- |
Description
Bill Skellenger
2007-01-15 00:50:42 UTC
Additional weirdness -- apparently I do have ghostscript-esp? WTF. gladstone ~ # emerge ghostscript-gpl Calculating dependencies... done! !!! Error: the app-text/ghostscript-esp package conflicts with another package; !!! the two packages cannot be installed on the same system together. !!! Please use 'emerge --pretend' to determine blockers. For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked gladstone ~ # emerge -pv ghostscript-gpl These are the packages that would be merged, in order: Calculating dependencies... done! [blocks B ] app-text/ghostscript-esp (is blocking app-text/ghostscript-gpl-8.54) [ebuild N ] app-text/ghostscript-gpl-8.54 USE="X cups gtk -cjk -djvu -emacs -jpeg2k" 12,082 kB Total size of downloads: 12,082 kB gladstone ~ # emerge -C ghostscript-esp Nothing we could fix here; re-emerge anything that depends on non-existant stuff for you, nothing in the tree does. (In reply to comment #2) > Nothing we could fix here; re-emerge anything that depends on non-existant > stuff for you, nothing in the tree does. I think there is a larger bug with virtual handling here although I'm not sure how to prove it -- My portage tree is on an nfs share as I mentioned. Still, even after getting rid of ghostscript-esp and emerging ghostscript-gpl, I still can't emerge cups-pdf (or cups): ----------------- gladstone ~ # emerge --debug cups-pdf myaction None myopts ['--debug'] Calculating dependencies Parent: None Depstring: net-print/cups-pdf Candidates: ['net-print/cups-pdf'] ebuild: net-print/cups-pdf-2.4.2 - Parent: ebuild / net-print/cups-pdf-2.4.2 merge Depstring: net-print/cups virtual/ghostscript net-print/cups virtual/ghostscript Candidates: ['app-text/ghostscript'] emerge: there are no ebuilds to satisfy "app-text/ghostscript". (dependency required by "net-print/cups-pdf-2.4.2" [ebuild]) gladstone ~ # ------------- Notice how it thinks that app-text/ghostscript is a candidate? My Portage tree is at /mnt/nfs_portage and app-text/ghostscript isn't there: gladstone app-text # pwd /mnt/nfs_portage/app-text gladstone app-text # ls | grep ghost ghostscript-esp ghostscript-gnu ghostscript-gpl So somehow it is finding app-text/ghostscript on my local machine, probably in the old portage directory that portage shouldn't be looking in: gladstone app-text # locate app-text | grep port | grep ghost /usr/portage/app-text/ghostscript /usr/portage/app-text/ghostscript/Manifest /usr/portage/app-text/ghostscript/ghostscript-7.07.1-r10.ebuild /usr/portage/app-text/ghostscript/files In /etc/make.conf, I've pointed PORTDIR: PORTDIR="/mnt/nfs_portage" DISTDIR="${PORTDIR}/distfiles" PKGDIR="${PORTDIR}/packages" recursive grep for ghostscript in /etc/portage Last time I bothered the portage developers about this it was because whoever owned the system before me had put some stuff in there. (In reply to comment #4) > recursive grep for ghostscript in /etc/portage > Last time I bothered the portage developers about this it was because whoever > owned the system before me had put some stuff in there. gladstone portage # pwd /etc/portage gladstone portage # fgrep -r ghost * gladstone portage # (nothing) This is certainly the long way to do it, but... debugging to follow: In portage.py: # This breaks catalyst/portage when setting to a fresh/empty root. # Virtuals cannot be calculated because there is nothing to work # from. So the only ROOT prefixed dir should be local configs. #myvirtdirs = prefix_array(self.profiles,myroot+"/") myvirtdirs = copy.deepcopy(self.profiles) Herein lies the problem (from within Python debugger): (Pdb) p self.profiles ['/usr/portage/profiles/base', '/usr/portage/profiles/default-linux', '/usr/portage/profiles/default-linux/x86', '/usr/portage/profiles/default-linux/x86/2005.0'] Now I go to my drive to check: gladstone profiles # pwd /usr/portage/profiles gladstone profiles # fgrep -R ghost * base/virtuals:virtual/ghostscript app-text/ghostscript updates/2Q-2005:move app-text/gnu-ghostscript app-text/ghostscript-gnu use.local.desc:media-gfx/graphicsmagick:gs - enable ghostscript support Summary: My *updated* profiles live on /mnt/nfs_portage (an always-on P200 in my basement). For some reason self.profiles in portage.py does not point to /mnt/nfs_portage despite the fact that I tell it to in make.conf? Here is the comment in make.conf: # PORTDIR is the location of the portage tree. This is the repository # for all profile information as well as all ebuilds. This directory # itself can reach 200M. WE DO NOT RECOMMEND that you change this. PORTDIR="/mnt/nfs_portage" (So this could be my issue, something I didn't set properly -- anyone know what? Next I'll try to investigate where the profiles come from) After finding out how the profile dirs are set, I found a different set of comments in make.conf.example # PORTDIR is the location of the portage tree. This is the repository # for all profile information as well as all ebuilds. If you change # this, you must update your /etc/make.profile symlink accordingly. #PORTDIR=/usr/portage This was the problem. I changed the make.profile symlink to point to a profile in /mnt/nfs_portage and I'm back in business. I'll mark it is invalid -- maybe the documentation here will help someone if they search Bugzilla in the future. |