I have emerged emacs, but not xemacs. There are ebuilds for ilisp both emacs and xemacs. However, if I "emerge ilisp" portage doesn't pick the emacs one, but starts to install xemacs! Trivial to cope with, but surely The Wrong Thing?
ispell also has a problem ... if you guys dont wish to change the current setup, file this bug as portage and request that when a user types `emerge <blah>` and blah matches more than 1 pkg, portage show the matching packages and quit with 'more than 1 package matched request'
yeah i noticed there is a few of them. not sure how this can be fixed. maybe a check for wether xemacs or emacs is installed and install the appropriate one. maybe this warants a new USE flag for xemacs and emacs. Matt any ideas on how we can fix this ??
Hi. I'm thinking the user needs to provide a "fully qualified" package nane (just as we specify DEPEND in ebuilds). emerge app-emacs/ilisp as opposed to the shorter, emacs ilisp So is this really a bug?
thats what i was thinking about 20 mins ago. shall we close it ?? or do people have a problem with this?
*** Bug 14114 has been marked as a duplicate of this bug. ***
you guys should hand this up to carpaski too ... see my comment #1 ...
imho having to specify a "fully qualified" package name would get annoying very fast
Well then... I guess the requirements are as follows: * for those of us who actually know what we're emerging, specifying "emerge app-emacs/ilisp" should continue to work. * for those that didn't know package names are not unique, emerge should fail and print out a list of fully qualified package names. Reassigning this to carpaski.
ocould that be based on wether you have emacs or xemacs installed ?? and maybe installing both if you have both installed ??
why not just rename app-xemacs/ispell to app-xemacs/xemacs-ispell or something more descriptive?
Seemant: because its ugly and un-needed. Whats the point of categories, if we prefix ebuild names with a namespace. bug 14114 and this bug should be closed as invalid IMO.
I guess i should describe my stake in this "bug"... app-emacs has dozens of ebuild names which overlap with app-xemacs. This is intentional. If a user types "emerge -p ilisp" intending to get the emacs version, they will instead get app-xemacs/ilisp (and probably every dependency down to installing xemacs itself). At that point the user will think "Gee, i want the app-emacs version not the xemacs one... I guess i should be more specific." and then run "emerge app-emacs/emacs". End of story. I'm sure renaming app-emacs/foo to app-emacs/emacs-foo several dozen times is not a good precedent. In fact, it looks like needless duplication of the category namespace into the ebuild name to me. I'd like to see this bug resolved INVALID.
I fell into this trep twice myself ... So I agree with the bug's submitter: This is a problem and it should be fixed. IMHO, portage should issue an error and abort if the package name is not unique.
i thought i had already posted a patch for this to bugzilla... but here it is again: http://emu.gentoo.org/~mkennedy/emerge-2.0.48-r1-shortname.patch
that patch is 404 atm.
http://dev.gentoo.org/~mkennedy/dump/emerge-2.0.48-r1-shortname.patch
Normally I wouldn't ask for an ETA, but its been almost a year.
*** This bug has been marked as a duplicate of 22699 ***
