I noticed that sys-libs/libsystem and sys-libs/ncurses are actually empty ebuilds. Are they still needed? They had been created before package.provided was implemented, and I suppose they are confusing as to be placed in CVS (especially ncurses). I understand they are placeholders for ppc-darwin, but I suggest we remove them and use package.provided until we are ready.
pvdabeel: perhaps you can shed light on this?
*** Bug 90714 has been marked as a duplicate of this bug. ***
ncurses-8.1 has been removed from the tree. Checking with kito about libsystem... we may want this when we actually build a pure gentoo/darwin system...
That's what package.provided is for, please remove this.
portage doesn't know what libc there is without this package: virtual/os-headers: [Not Present] it simply doesn't cope with a package.provided package to satisfy the virtual. I'd like to keep the package to keep the headers filled in, unless someone from the portage team can tell me that this won't break anything. With the virtual pointing to a package.provided package: % emerge --info !!! Relying on the shell to locate gcc, this may break !!! DISTCC, installing gcc-config and setting your current gcc !!! profile will fix this Portage 2.1_rc2 (default-darwin/macos/10.4, gcc-4.0.1, unavailable, 8.6.0 Power Macintosh) ================================================================= System uname: 8.6.0 Power Macintosh powerpc macos-20041118 distcc 2.18.3-Apple powerpc-apple-darwin8.0 (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: [Not Present] dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: [Not Present] sys-devel/autoconf: [Not Present] sys-devel/automake: [Not Present] sys-devel/binutils: [Not Present] sys-devel/libtool: [Not Present] virtual/os-headers: [Not Present] ACCEPT_KEYWORDS="ppc-macos" AUTOCLEAN="yes" CBUILD="powerpc-apple-darwin8" CFLAGS="-O3 -pipe" CHOST="powerpc-apple-darwin8" ...
(In reply to comment #5) > I'd like to keep the package to keep the headers filled in, unless someone from > the portage team can tell me that this won't break anything. Providing the dependency via package.provided is effectively the same as having the dummy package installed. There is no difference as far as portage is concerned.
(In reply to comment #5) > portage doesn't know what libc there is without this package: > virtual/os-headers: [Not Present] ... > sys-devel/autoconf: [Not Present] > sys-devel/automake: [Not Present] > sys-devel/binutils: [Not Present] > sys-devel/libtool: [Not Present] > virtual/os-headers: [Not Present] Portage itself doesn't care about those packages in any way.
Before I remove this package from the tree, can someone from the portage team fix this: % emerge --info Portage 2.1.1_pre1-r1 (default-darwin/macos/10.4, gcc-4.0.1, unavailable, 8.6.0 Power Macintosh) ================================================================= System uname: 8.6.0 Power Macintosh powerpc macos-20041118 distcc 2.18.3-Apple powerpc-apple-darwin8.0 (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: [Not Present] dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: [Not Present] sys-devel/autoconf: [Not Present] sys-devel/automake: [Not Present] sys-devel/binutils: [Not Present] sys-devel/gcc-config: [Not Present] sys-devel/libtool: [Not Present] Traceback (most recent call last): File "/usr/bin/emerge", line 3177, in ? pkg_matches = portage.db["/"]["vartree"].dbapi.match(x) File "/usr/lib/portage/pym/portage.py", line 4679, in match mymatch=match_from_list(mydep,self.cp_list(mykey,use_cache=use_cache)) File "/usr/lib/portage/pym/portage.py", line 3966, in match_from_list raise KeyError, "Specific key requires an operator (%s) (try adding an '=')" % (mydep) KeyError: "Specific key requires an operator (sys-darwin/libsystem-71) (try adding an '=')" it happens with libsystem unmerged and the virtual/os-headers pointing to a package.provided package. It effectively prevents me from emerging anything. Making the virtual point to an invalid package makes things work again. If necessary, I can open a new bug for this.
Uhm sorry, the error is because of a User-Error(tm). (No version allowed) I just get confused by Python stack traces :) Seems to work, so sys-libs/libsystem is gone.
