When using emerge, different situations require different ways of specifying packages / ebuilds. For example: 1) emerge -u gimp 2) emerge -i media-gfx/gimp-1.2.5 3) emerge -p media-gfx/gimp/gimp-1.3.20-r1.ebuild Sometimes it will try to find packages in each category, sometimes it won't. 2 and 3 can be derived from each other; both could be derived from package-version if the package was unique across all categories. It would be nice if 2 and 3 worked everywhere; it would be nicer if the category was always optional when the package was unambiguous. Any time the required information (package, sometimes the category, sometimes the version) can be derived, it should be. If a given method is not available for a certain command, specify the proper format. -i does this already: ``gimp is not a specific cat/pkg-version, skipping...'' Others like -p do not: ``there are no masked or unmasked ebuilds to satisfy "media-gfx/gimp-1.3.20-r1"'' Reproducible: Always Steps to Reproduce: 1. e.g. emerge -p media-gfx/gimp-1.3.20-r1 2. 3. Actual Results: Actual Results: Error because package specifying formats are inconsistent Expected Results: Expected Results: Emerge finds packages or tells me what I'm doing wrong emerge info: Portage 2.0.49-r3 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.21) ================================================================= System uname: 2.4.21 i686 AMD Athlon(TM) XP 2700+ ccache version 2.2 [enabled] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb:/usr/kde/3.1/share/config:/usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 apm cups foomaticdb libg++ mad nls truetype xml2 gdbm berkdb slang svga tcltk java guile sdl gpm tcpd libwww gtk qt motif -gnome -acpi -alsa -arts -esd -pam 3dnow aalib avi cdr cjk crypt doc dvd encode gif imlib jpeg kde mbox mikmod mmx mmxext mpeg ncurses oggvorbis opengl oss pdflib perl png postgres python quicktime readline scanner spell ssl tetex tiff X xmms xv zlib"
i dont see the problem with #3 ... you are supposed to use =media-gfx/gimp-1.3.20-r1 ... you can specify the ebuild, but it most be the full path (or PWD + relative path) ...
The problem is, why should I have to specify the full path, or use = for that matter? I didn't have to for other commands. It's possible for emerge to look at "media-gfx/gimp-1.3.20-r1" and figure out what I'm trying to specify -- demonstrably so, as -i uses exactly this format! "Be lenient in what you accept". So right now, I'm supposed to use = or a path, as you say. The request for enhancement is, allow me to use other formats which are already accepted by other emerge commands. More generally, any format that can be used in one part of emerge should be usable by all parts of emerge. Be consistent. The only exception is if there's not enough information, like when a command requires a specific version, or the package name is ambiguous because it shows up in more than one category. In which case, tell the user what they need to do, like -i does now. As an end user, here's how I'd expect 3 in specific to work on a couple levels. emerge -p media-gfx/gimp-1.3.20-r1 emerge looks for a package gimp in category media-gfx and finds it, finds the 1.3.20-r1 ebuild, tells me what would happen if I were to install that ebuild emerge -p gimp-1.3.20-r1 emerge figures out I'm talking about a gimp packages, looks in all the categories as it would for `emerge -u gimp` and finds no ambiguity -- only the category media-gfx has that package. The rest is the same.
because of the context ... portage is consistent in how it does things in each context injecting takes a specific category/package-version, putting a version operator on there (=, <, >, etc...) is stupid emerging takes depend atoms (read `man 5 ebuild` for more about what a depend atom is) thus you can specify a depend atom to emerge. atoms are affected by masking and all the safe guards that portage has in place to keep broken things from hitting a users system the fact you can give portage an ebuild or a tarball is provided as a last ditch effort to get around the safe guards ... about the only change i would have added from this bug is making a leading = implicit when emerging stuff ... which would satisfy what you're looking for it would seem
Making the = implicit does solve most of the problems, so I'm all for that. I'm also for making the error message more verbose, or at the very least, tell the user where to find instructions on these different contexts. Another suggestion is to also update the emerge man page, so that it reflects these contexts. The -i flag explanation (and error message) gives the format, but the synopsis implies -i would use ``[ebuild | tbz2file | class | dependency]''. If these different syntaxes aren't going away, at least let the user know that these situations exist. I think the above are good ideas. As you seem to think they're acceptable as well, please don't let the rest of the message get in the way of the above. I'd rather have this mostly-solved than not-solved. Reading the ebuild(5) page does clear up the syntax a bit. However, the emerge man page presents the syntax as 6 groups (including -i), and doesn't seem to reflect what is actually happening. There's "class" syntax, which I'll ignore. There's "tbz2file" syntax, which I'll also ignore. Then there's "ebuild" syntax, "dependency" syntax, and "-i" or "single version" syntax. There's also "ebuildfile" which is missing it's explaination in the man page. Under the explaination for "ebuild" syntax, it mentions you can specify an actual filename. I'm sure that's really what "ebuildfile" is. So I'll consider using a filename to be "ebuildfile" syntax and not "ebuild" syntax. The rest of "ebuild" syntax is presented as being one of: "pkg", "cat/pkg", "=pkg-vers", "=cat/pkg-vers" Technically, using the man 5 ebuild page as a formal definition of a depend atom, "cat/pkg" and "=cat/pkg-vers" should both be under the "dependency" group. Actually, you can see that "=pkg-vers" works like a dependency in general: emerge -p \<gimp-1.2.4 If we always consider the category to be optional, these are *all* part of the "dependency" group. It's just that = is already implicit if you don't specify a version. Making it implicit everywhere makes sense. Making the category optional also makes sense, at least when there's no ambiguity. (I can see why you might want to require the category for ebuild files, but remain lenient on the command line) So unless there're some other custom syntaxes for commands I haven't hit yet, we're really only talking about "dependency" syntax (with optional category), and "single version" dependency. The overlap is almost complete. With the implicit "=", "single version" syntax is a very small subset of "dependency". Why not just use "dependency"? Here are some reasons why I think it makes sense. First of all, it's a bad idea to assume allowing a version operator is stupid. Maybe some user wants to inject all versions > 3 of package foo. It's a bad idea to add limitations because "the user will never want this", and I believe in letting users shoot themselves in the foot. And maybe only one version matches! Even if you don't like that idea, just look for situations where more than one version is chosen. You could always require some --force flag to inject more than one version at once, or give one of those warning/beeping screens. But even if you flat out refuse to operate on more than one version at a time, allowing the version operator is *still* a good idea! The reason is *it makes emerge as a whole use consistent syntax*. I'm glad that within the context of each command, the syntax is consistent -- I would sure hope so! But it's *inconsistent* across emerge as a whole, and it doesn't have to be. They are extremely alike. Special-casing the syntax (as opposed to the action) violates the principal of least astonishment. Why can't I do something like: emerge -i libfoo "emerge -p libfoo" worked after all! The *user* does not care about the technical reasons underlying the problem. So, -i will only operate on a single version of a particular package. Well, when I'm using emerge in other contexts, I'm usually only working on a single version of a particular package as well! In that respect -- to the user -- the context never changed. The user doesn't want to think about what's going on behind the scenes. Even if they did, there're more ways to specify a single version of a particular package. As it so happens, the implicit = seems to fix everything except for the fact that -i can't take general "dependency" syntax. Letting -i take the general syntax would make it consistent across all of emerge, and I think it's definitely worth it. The only difference I haven't addressed is that -i "turns off" (does not check) things like masking. Having a "~arch" in the KEYWORDS for example. As far as I can tell, the only other time these checks are not performed is if the ebuild file itself is specified. I think having a general flag to turn off the checks would be useful. Then I could do something like emerge --nomask =gimp-1.3.20-r1 Then -i would imply --nomask. If you don't want to deal with this here, I can file a seperate request for that flag.
*** Bug 30376 has been marked as a duplicate of this bug. ***
This bug seems to be more of a book... As for the summary... That can be worked on. I didn't look at any of the other things mentioned. Post seperate bugs for things not matching the summary. Brief is better.
*** Bug 37877 has been marked as a duplicate of this bug. ***
*** Bug 37929 has been marked as a duplicate of this bug. ***
*** Bug 37933 has been marked as a duplicate of this bug. ***
*** Bug 38063 has been marked as a duplicate of this bug. ***
*** Bug 38150 has been marked as a duplicate of this bug. ***
*** Bug 38344 has been marked as a duplicate of this bug. ***
Maybe if someone updated the damn man pages to show the correct syntax we would not be opening all these bug reports.... take a gander at "man emerge" Look at the "unmerge" action section. It says look at the "clean" action section for proper syntax. The "clean action" says proper syntax when refering to an installed package is without the = . Here is a quote: "emerge clean net-www/mozilla-0.9.9-r2 cleans out that specific version of Mozilla." NO "=" guys! If you are going to take away the ability to use emerge without = then fix the docs FIRST! Aparently all that time checking the docs was a huge ass waste as now emerge is used different from the docs.
Created attachment 23889 [details, diff] Fixed the man page to correctly explain ebuild needing = Please apply or come up with a better man page on your own... ;)
well the idea here is that when used on the cmdline, it's *really* nice to not have to prefix with = so we leave the docs alone and make this valid again :)
I think in the long run most people don't give a rats ass either way. I know I sure don't. I just want to be able to read the docs/manpage and figure out what is going on, and adjust my "evil/wrong" ways without wasting time opening a bug report. If you guys want to enforce =, then great, whatever, most won't really care as long as your constistant and it's documented. Yes there will be several people who continue to wine, but it will die off in a couple months/weeks. Any new bugs opened can simply be closed with "RTFM RESOLVED".
Well, it's not consistent overall, as explained above. In summary, ``Why can't I do something like: "emerge -i libfoo"? "emerge -p libfoo" worked after all!'' Also, it's an enhancment request, resolution would be WONTFIX. Your patch doesn't address the request, although it could be said to fix a bug of incorrect documentation. (Tangentially, whatever the end result is, man 5 ebuild should be checked for accuracy as well). I think just documenting a bad interface instead of fixing the interface is a bad idea. There've been 6 duplicate bug reports on it in 5 days, and there will probably be more. Ignoring users on something as intuitive as this is a great way to make a horrible program. Especially since it seems from other reports that the = is no longer implicit in places where it has been before. At any rate, I think the best thing to do would be to make the = implicit. That solves most of the problem, including the source of every bug report I see.
*** Bug 38543 has been marked as a duplicate of this bug. ***
Now we can use 'emerge foo-1.0.0 unmerge' but we can't use 'emerge foo-1.0.0'. (But .50pre* is broken in this part. I fixed it in CVS.) It seems strange. If we decided to allow 'foo-1.0.0 unmerge' before, we should allow 'emerge foo-1.0.0'. carpaski and all: what do you think?
I agree. Working with versions of packages is very useful, and using full path of the ebuild is so annoying...
*** Bug 38620 has been marked as a duplicate of this bug. ***
I just got this error doing: emerge -upDv world My comment: A user needs an error message that is meaningful to the user, not a Python traceback. It seems to me the data validation routine(s) need to be enhanced to provide this error message. In my case, since I'm trying to emerge world, how do I determine what key is blowing portage up? Traceback is: bash-2.05b# emerge -upDv world These are the packages that I would merge, in order: Calculating world dependencies -Traceback (most recent call last): File "/usr/bin/emerge", line 2502, in ? if not mydepgraph.xcreate(myaction): File "/usr/bin/emerge", line 1124, in xcreate if not self.create(myk): File "/usr/bin/emerge", line 821, in create if not self.select_dep("/",mydep["/"],myparent=mp,myuse=myuse): File "/usr/bin/emerge", line 932, in select_dep mycheck=portage.dep_check(depstring,self.mydbapi[myroot],self.pkgsettings,myuse=myuse) File "/usr/lib/portage/pym/portage.py", line 3294, in dep_check mysplit2=dep_wordreduce(mysplit2,mydbapi,mode) File "/usr/lib/portage/pym/portage.py", line 3322, in dep_wordreduce mydep=mydbapi.match(deplist[mypos]) File "/usr/lib/portage/pym/portage.py", line 3724, in match return match_from_list(mydep,self.cp_list(mykey,use_cache=use_cache)) File "/usr/lib/portage/pym/portage.py", line 3468, in match_from_list raise KeyError, "Specific key requires an operator (%s) (try adding an '=')" % (mydep) KeyError: "Specific key requires an operator (sys-devel/gcc-3.3.2) (try adding an '=')" Emerge info: Portage 2.0.50_pre22 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040117-r0, 2.6.1-gentoo-r1) ================================================================= System uname: 2.6.1-gentoo-r1 i686 AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.4.3.12 Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /opt/tomcat/conf /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-mcpu=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox usersandbox" GENTOO_MIRRORS="ftp://mirror.iawnet.sandia.gov/pub/gentoo/ http://gentoo.seren.com/gentoo ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo/" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d acl acpi acpi4linux alsa amd antlr apache2 apm arts artswrappersuid avi berkdb bonobo cdr crypt cups directfb dnd doc dv dvd dvdr encode esd ethereal evo fbcon fbdev foomaticdb foreign-package foreign-sysvinit freetds gb gd gd-external gdbm gif ginac gnome gnomedb gpm gstreamer gtk gtk2 gtkhtml guile imap imlib innodb ipv6 java jikes jpeg junit kde kerberos ldap libg++ libgda libwww mad maildir mbox mdb mikmod mmx motif mozilla moznoirc moznomail mpeg mysql ncurses nls nptl oci8 odbc ofx oggvorbis opengl oss pam pda pdflib perl pg-hier pic plotutils png postgres ppds python qt quicktime radeon readline ruby ruby18 samba sasl sdk sdl slang slp snmp spell sse ssl svga tcltk tcpd tetex tiff truetype type1 usb wmf wxwindows x86 xml xml2 xmms xv zeo zlib"
The error does not apply to me. p2p@cerrito on GSM p2p $ id uid=1004(p2p) gid=100(users) gruppi=100(users) p2p@cerrito on GSM p2p $ emerge -upDv world *** You are not in the portage group. You may experience cache problems *** due to permissions preventing the creation of the on-disk cache. *** Please add this user to the portage group if you wish to use portage. These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild UD] x11-base/xfree-4.3.0-r3 [4.3.99.902] -3dfx -3dnow -cjk -debug -doc -gatos -ipv6 +mmx +nls +pam -sdk +sse -static +truetype +xml2 67,186 kB [ebuild U ] kde-base/arts-1.2.0 [1.2.0_rc1] +alsa -artswrappersuid +esd +mad +oggvorbis 0 kB [ebuild U ] kde-base/kdelibs-3.2.0 [3.2.0_rc1] +alsa +cups -doc -ipv6 +ldap +ssl 12,161 kB [ebuild U ] kde-base/kdebase-3.2.0 [3.2.0_rc1] +cups +encode +java +ldap +motif +opengl +pam +samba +ssl 16,996 kB [ebuild U ] kde-base/kdeutils-3.2.0 [3.2.0_rc1] 2,458 kB [ebuild U ] kde-base/kdemultimedia-3.2.0 [3.2.0_rc1] +alsa +encode +esd -gstreamer +gtk +motif +nas +oggvorbis +slang +tcltk 4,778 kB [ebuild U ] net-wireless/linux-wlan-ng-0.2.1_pre17 [0.2.1_pre11] -build +pcmcia +usb 0 kB [ebuild U ] kde-base/kdenetwork-3.2.0 [3.2.0_rc1] +samba -slp 5,969 kB [ebuild N ] sys-apps/thinkpad-4.8 0 kB [ebuild U ] kde-base/kdeadmin-3.2.0 [3.2.0_rc1] +pam 1,524 kB [ebuild N ] kde-base/kdegraphics-3.2.0 -gphoto2 +opengl +scanner +tetex 5,539 kB [ebuild N ] kde-base/kdepim-3.2.0-r2 +crypt +ldap -pda 7,527 kB [ebuild N ] kde-base/kdeaddons-3.2.0 +esd +sdl +svga +xmms 1,281 kB [ebuild U ] kde-base/kdeartwork-3.2.0 [3.2.0_rc1] +opengl 16,753 kB Total size of downloads: 142,178 kB p2p@cerrito on GSM p2p $ emerge info Portage 2.0.50_pre22 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040117-r0, 2.6.1-gentoo-r1) ================================================================= System uname: 2.6.1-gentoo-r1 i686 Intel(R) Pentium(R) III Mobile CPU 1200MHz Gentoo Base System version 1.4.3.12 Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -mfpmath=sse -O2 -fPIC -pipe -fomit-frame-pointer -mmmx -msse -falign-functions=32 -fforce-addr" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -mfpmath=sse -O2 -fPIC -pipe -fomit-frame-pointer -mmmx -msse -falign-functions=32 -fforce-addr" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://212.219.56.162/sites/www.ibiblio.org/gentoo/ http://194.83.57.2/sites/www.ibiblio.org/gentoo/ http://194.83.57.3/sites/www.ibiblio.org/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://ftp.flashnet.it/mirror/12/sunsite.unc.edu/Gentoo ftp://ftp.unina.it/pub/linux/sunsite http://ibiblio.org/pub/Linux/ftp.edisontel.com/pub/Sunsite_Mirror http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo ftp://sunsite.cnlab-switch.ch/mirror/gentoo http://www.ibiblio.org/pub/Linux/distributions/gentoo http://gentoo.oregonstate.edu" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/portoverlay" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acl acpi alsa apm arts avi berkdb bluetooth bonobo cdr crypt cups dga directfb dvd encode esd fbcon foomaticdb gdbm gif gnome gpm gtk gtk2 gtkhtml guile imlib irda java jpeg kde kerberos krb4 ldap libg++ libwww linguas_it mad mikmod miknod mmx mng motif mozilla mpeg nas ncurses nls oggvorbis opengl oss pam pcmcia pdflib perl pic png pnp python qt quicktime radeon readline ruby samba scanner sdl slang socks5 spell sse ssl svga tcltk tcpd tetex truetype usb video_cards_radeon x86 xml2 xmms xv zlib"
cerrito: why did you post that when's it completely unrelated ? in fact, i dont even see a problem with what you posted
SpanKY, I believe Comment #23 is in reply to my Comment #22. Today, I tried emerge -upDv world and I got the results in Comment #22. I'm posting this here since this bug is marked as the original for Bug #38620 (see comment #21). I'm not sure that Bug #38620 really is a duplicate of this bug, but that's what Marius marked it. (I'm sure he understands Portage better than me!)
SpanKY, my reply is related to Howard B. Golden post. I saw he was running a beta version of portage (like me), so I tried to reproduce his error, without success.
my mistake then
*** Bug 40663 has been marked as a duplicate of this bug. ***
*** Bug 40719 has been marked as a duplicate of this bug. ***
*** Bug 42038 has been marked as a duplicate of this bug. ***
*** Bug 44479 has been marked as a duplicate of this bug. ***
Closing this. emerge category/package-version ain't valid, use emerge =category/package-version It may be annoying, but this is the syntax that was defined, and it's pretty much the most natural atm- it's normal atom syntax.
