Today I try to (re)emerge cups: ---------------------------------- gladstone ~ # emerge -pv cups These are the packages that would be merged, in order: Calculating dependencies - emerge: there are no ebuilds to satisfy "app-text/ghostscript". ---------------------------------- Reproducible: Always Steps to Reproduce: Since I'm running portage over nfs (box in the basement resyncs weekly), I decided to emerge --metadata and try this command again. I got the same thing. I tried --debug on a whim and was pleasantly surprised to get a very verbose output: gladstone ~ # emerge --debug cups myaction None myopts ['--debug'] Calculating dependencies Parent: None Depstring: net-print/cups Candidates: ['net-print/cups'] ebuild: net-print/cups-1.2.6 - Parent: ebuild / net-print/cups-1.2.6 merge Depstring: pam? ( virtual/pam ) ssl? ( net-libs/gnutls ) slp? ( >=net-libs/openslp-1.0.4 ) dbus? ( sys-apps/dbus ) png? ( >=media-libs/libpng-1.2.1 ) tiff? ( >=media-libs/tiff-3.5.5 ) jpeg? ( >=media-libs/jpeg-6b ) php? ( dev-lang/php ) app-text/libpaper nls? ( sys-devel/gettext ) || ( =sys-devel/automake-1.10* =sys-devel/automake-1.9* ) >=sys-devel/autoconf-2.59 sys-devel/libtool pam? ( virtual/pam ) ssl? ( net-libs/gnutls ) slp? ( >=net-libs/openslp-1.0.4 ) dbus? ( sys-apps/dbus ) png? ( >=media-libs/libpng-1.2.1 ) tiff? ( >=media-libs/tiff-3.5.5 ) jpeg? ( >=media-libs/jpeg-6b ) php? ( dev-lang/php ) app-text/libpaper nls? ( virtual/libintl ) !virtual/lpr >=app-text/poppler-0.4.3-r1 X? ( x11-misc/xdg-utils ) Candidates: ['!net-print/cups'] Myparent ebuild / net-print/cups-1.2.6 merge Exiting... ebuild / net-print/cups-1.2.6 merge Parent: None Depstring: ppds? ( || ( ( net-print/foomatic-filters-ppds net-print/foomatic-db-ppds ) net-print/foomatic-filters-ppds net-print/foomatic-db-ppds net-print/hplip media-gfx/gimp-print net-print/foo2zjs net-print/cups-pdf ) ) samba? ( >=net-fs/samba-3.0.8 ) virtual/ghostscript Candidates: ['app-text/ghostscript'] emerge: there are no ebuilds to satisfy "app-text/ghostscript". ------------- What I can gather from the above: Sometime in the past couple of years, it seems that app-text/ghostscript has taken on three distinct flavors: ghostscript-esp, ghostscript-gnu, ghostscript-gpl What about those of us who apparently have the "old" app-text/ghostscript installed? Since this ebuild no longer exists, anything depending on virtual/ghostscript will (apparently) bomb. It appears I'm seeing several (closed) bugs on this topic (but not exactly the same -- I'm running an OLD ghostscript that is no longer recognized by portage): 141250, 141829, 144751, 161418 Expected Results: From the Gentoo ebuild policy: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 o Your package, when complete and unmasked, is supposed to "just work" for the end-user. Tweaking the installed product to get it to work should be optional; thus you need to install the package with reasonable default settings.
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.
