Searching for "pgplot" turns up two packages: $ eix --only-names pgplot dev-perl/PGPLOT sci-libs/pgplot $ Whereas specifying "PGPLOT" results in an empty list: $ eix --only-names PGPLOT $ eix --only-names -e PGPLOT $ For "FCGI" things work as expected, though: $ eix --only-names FCGI dev-libs/fcgi dev-perl/FCGI dev-perl/FCGI-ProcManager dev-ruby/fcgi www-apache/mod_fcgid www-misc/fcgiwrap www-servers/spawn-fcgi $ eix --only-names -e FCGI dev-perl/FCGI $
It's not a bug, it's a feature: Due to your search string containing GPL, eix defaults to searching the license field, see "eix --print DEFAULT_MATCH_FIELD". You explicitly have to specify --name to avoid that eix chooses the default field by the DEFAULT_MATCH_FIELD heuristics.
Note that the problem also occurs with the -e option: -e, --exact Pattern is an exact (full) string. For example, "eix -e gcc" will only show packages with the name "gcc". PGPLOT isn't an exact match for GPL, so even with your heuristic, why would it match that string in DEFAULT_MATCH_FIELD? (Also, by generalisation of the man page's example, I would expect that: '"eix -e PGPLOT" will only show packages with the name "PGPLOT".')
(In reply to Ulrich Müller from comment #2) > Note that the problem also occurs with the -e option: Of course, because -e only specifies the search _algorithm_, not the search _field_. Both must be specified if you do not want them to be chosen by some heuristic, each. The heuristic for the search algorithm is specified in DEFAULT_MATCH_ALGORITHM, the heuristic for the field in DEFAULT_MATCH_FIELD. > PGPLOT isn't an exact match for GPL, so even with your heuristic, why would > it match that string in DEFAULT_MATCH_FIELD? Because the heuristic works by regular expressions. If you would want an exact match only, one would have to specify ^GPL$, but this would be a bad idea, because it would miss e.g. LGPL or GPL-2. I am aware that this is only a heuristics and sometimes confusing: This is not the first bug report caused by a misunderstanding of the mechanism. OTOH, the number of false guesses is rather low meanwhile, and in most cases the heuristics gives the user "more expected" results than if a fixed default without any heuristics would be used. (Of course, you can simply change this by specifying DEFAULT_MATCH_FIELD and DEFAULT_MATCH_ALGORITHM on your own in e.g. /etc/eixrc). "G_GPL_OT" is really an unlikely unfortunate false positive for the expression.
This goes against the principle of least surprise. It is reasonable when the heuristic is triggered by strings like " ", "/", or "@" which are not allowed in package names. But IMHO it should never kick in on strings like "BSD" or "GPL" which are legal as part of a package name. (And both actually occur in the tree, namely in dev-perl/BSD-Resource and dev-perl/PGPLOT, so this is a real issue and not just an academic example.) I would therefore suggest to drop GPL|BSD|Art from DEFAULT_MATCH_FIELD.
(In reply to Ulrich Müller from comment #4) > This goes against the principle of least surprise. Any heuristic goes against the principle of least surprise. But such a heuristic was built into eix from almost the first version, so removing it now would also go against the principle of least surprise. > dev-perl/BSD-Resource That's a very good argument. > I would therefore suggest to drop GPL|BSD|Art from DEFAULT_MATCH_FIELD. I agree. Maybe the same should happen for the eapi heuristics which also already confused users. I still have to think about how to do this without destroying the meaning of the MATCH_FIELD_LICENSE and MATCH_FIELD_EAPI variables which some users might have configured.
Fixed on eix master branch on github
(In reply to Martin Väth from comment #5) > Maybe the same should happen for the eapi heuristics [...] Well, technically an all-digits package name would be valid. On the other hand, EAPI names aren't bound to be numerical only (though currently all council approved ones are).
(In reply to Ulrich Müller from comment #7) > EAPI names aren't bound to be numerical only _Practically_ they are (except testing ones), and there is no reason to assume that this practice will change. Even if it does some day (e.g. if after "9" there will be "a"), it would be easy enough to change in the heuristics: new EAPI features sometimes require certain changes in eix, anyway. However, I have removed the eapi heuristics now for another reason: > an all-digits package name would be valid. The problem is that an all-digits query does not mean that the user is looking for an all-digits field. One would have to make the heuristic even smarter and make it dependent on whether e.g. the user explicitly specified "-e" or something similar. The current heuristics has confused already at least some users.
Seems to be fixed long ago
