I tried to execute the "config" of several ebuilds, following happens ebuild /var/db/pkg/dev-db/postgresql-8.0.4/postgresql-8.0.4.ebuild config Adjusting PORTDIR to '/var/db/pkg'... --- 'profiles/arch.list' is empty or not available. Empty portage tree? !!! aux_get(): ebuild path for 'dev-db/postgresql-8.0.4' not specified: !!! None !!! aux_get(): ebuild path for 'dev-db/postgresql-8.0.4' not specified: !!! None Traceback (most recent call last): File "/usr/sbin/ebuild", line 55, in ? a = portage.doebuild(ebuild, arg, root, tmpsettings, debug=debug, cleanup=("noauto" not in portage.features)) File "/usr/lib/portage/pym/portage.py", line 2431, in doebuild eapi = db[root][tree].dbapi.aux_get(mycpv, ["EAPI"])[0] File "/usr/lib/portage/pym/portage.py", line 5277, in aux_get raise KeyError, "'%(cpv)s' at %(path)s" % {"cpv":mycpv,"path":myebuild} KeyError: "'dev-db/postgresql-8.0.4' at None" I also tried it with sys-apps/portage-2.0.51.22-r3 and it functions fine - so it should be a portage problem. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.53_rc5 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.13-gentoo-r2agpin i686) ================================================================= System uname: 2.6.13-gentoo-r2agpin i686 AMD Duron(tm) Processor Gentoo Base System version 1.6.13 ccache version 2.4 [enabled] dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X a52 acpi aim alsa apache2 apm arts avi berkdb bitmap-fonts ccache cdparanoia cdr cpudetection crypt cups curl dbus divx4linux dri dvd eds emboss encode fam ffmpeg foomaticdb ftp gd gdbm gif glx gnome gphoto2 gpm gstreamer gtk gtk2 hal ieee1394 imap imlib ipv6 java javascript jpeg jpeg2k junit kde kdeenablefinal latex lcms ldap libg++ libwww lm_sensors mad memlimit mikmod mmx mmxext motif mp3 mpeg ncurses nls nptl ogg oggvorbis opengl oscar oss pam pda pdflib perl png postgres ppds python qt quicktime readline real rtc samba scanner sdl session sharedmem slang spell sse ssl svg tcpd tetex tidy tiff truetype truetype-fonts type1-fonts unicode usb v4l v4l2 vcs vim-with-x vorbis webdav wifi win32codecs xine xml xml2 xmlrpc xmms xscreensaver xv yahoo zlib video_cards_radeon linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
This is a WONTFIX. You should use `emerge --config dev-db/postgresql` instead. Can the documentation be updated to reflect this please? Also, if possible, can the "ebuild application" section of the handbook be removed entirely and moved to the developer handbook please? Apart from the old "ebuild foo.ebuild config" hack, ebuild is not a user application.
Actually I have fixed it, but "ebuild" is still a dev tool rather than a user tool so I'll leave this bug with docs-.
*** Bug 109424 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Also, if possible, can the "ebuild application" section of the handbook be > removed entirely and moved to the developer handbook please? Apart from the > old "ebuild foo.ebuild config" hack, ebuild is not a user application. Agreed. As soon as it is available wherever it should be, I'll remove it from our handboook.
(In reply to comment #4) > Agreed. As soon as it is available wherever it should be, I'll remove it from > our handboook. If we're talking about `emerge --config foo`, it's available in current almost-everywhere-stable sys-apps/portage-2.0.53 (except mips and ppc-macos).
`emerge --config foo` is available in 2.0.51.22 as well.
status update on this one?
Well, comment #4 is still valid. We could extract that chapter and turn it into a "Using the ebuild application" stand-alone guide, if you like.
(In reply to comment #8) > Well, comment #4 is still valid. > We could extract that chapter and turn it into a "Using the ebuild application" > stand-alone guide, if you like. Looking at comments #5 and #6, how is #4 still valid?
Any news on this? Since, y'know, 2.0.54 is the "in" thing for arches, in some form or another. Still valid? Status?
The issue with the ebuild command was fixed. Not sure where the documentation stands. If usage of the ebuild command is still recommended to users, it needs to be updated with the appropriate emerge equivalent...
Doesn't matter that it's a developer tool. This guide is written in a very accessible way and explains a lot about how Gentoo does installations of packages. I think it's a very good guide and that it should stay as a part of the Handbook, which goal is to teach users the ways of Gentoo. My vote is for WONTFIX and leaving as-is. Any counter arguments?
(In reply to comment #12) > Doesn't matter that it's a developer tool. This guide is written in a very > accessible way and explains a lot about how Gentoo does installations of > packages. I think it's a very good guide and that it should stay as a part of > the Handbook, which goal is to teach users the ways of Gentoo. My vote is for > WONTFIX and leaving as-is. Any counter arguments? > Well, it's still not quite resolved, as now I guess we need a new bug to get the right commands updated for Portage 2.1. I agree, though, that a separate guide seems a bit much. jstubbs: what exactly should be updated then? has the actual command changed?
(In reply to comment #13) > (In reply to comment #12) > > Doesn't matter that it's a developer tool. This guide is written in a very > > accessible way and explains a lot about how Gentoo does installations of > > packages. I think it's a very good guide and that it should stay as a part of > > the Handbook, which goal is to teach users the ways of Gentoo. My vote is for > > WONTFIX and leaving as-is. Any counter arguments? > > Well, it's still not quite resolved, as now I guess we need a new bug to get > the right commands updated for Portage 2.1. I agree, though, that a separate > guide seems a bit much. > > jstubbs: what exactly should be updated then? has the actual command changed? The command hasn't changed at all. The problem is that users use it when they really don't need to which brings about bugs with regard to "world missing packages", inapproriately setting FEATURES="keepwork" and the like. I'm not suggesting that it be moved to its own guide, rather that it be moved to the developer guide that covers writing ebuilds, eclasses and whatever else as the ebuild tool is created specifically for developer purposes.
(In reply to comment #14) > The command hasn't changed at all. The problem is that users use it when they > really don't need to which brings about bugs with regard to "world missing > packages", inapproriately setting FEATURES="keepwork" and the like. > > I'm not suggesting that it be moved to its own guide, rather that it be moved > to the developer guide that covers writing ebuilds, eclasses and whatever else > as the ebuild tool is created specifically for developer purposes. Putting it in the dev manual sounds reasonable.
devmanual.gentoo.org or gentoo.org/proj/en/devrel/handbook?
both?
Okay. So now i'd like to hear from devrel and from plasmaroo if they want to take care of that chapter since now. As soon as they integrate it with their docs it will be removed from the user handbook. CCing all the parties involved.
(In reply to comment #18) > Okay. So now i'd like to hear from devrel and from plasmaroo if they want to > take care of that chapter since now. As soon as they integrate it with their > docs it will be removed from the user handbook. CCing all the parties involved. I've added some detail to http://devmanual.gentoo.org/ebuild-writing/functions -- there's not too much else that needs documenting from the current user handbook section IMO so feel free to scrap things from there now.
Removed from all our handbooks.
