Hello. I have =dev-python/numpy-1.10.4 installed from the main tree: $ cat /var/db/pkg/dev-python/numpy-1.10.4/repository gentoo I also have sage-on-gentoo overlay installed, which also provides =dev-python/numpy-1.10.4. Whatever I do, I cannot get `equery meta` to show me info from metadata.xml from the main tree. It always shows info from metadata.xml from sage-on-gentoo overlay. Moreover my `equery meta numpy` output looks like this: $ equery meta numpy * dev-python/numpy [gentoo] Maintainer: francois.bissey@canterbury.ac.nz (Francois Bissey) Maintainer: sci@gentoo.org (Gentoo Science Project) Maintainer: python@gentoo.org (Python) Upstream: Remote-ID: numpy ID: pypi Homepage: http://www.numpy.org/ Location: /var/lib/layman/sage-on-gentoo/dev-python/numpy [...] As you can see from `Location` field it uses info from sage-on-gentoo overlay, but the first line says `* dev-python/numpy [gentoo]`, which creates much confusion what this output really describes. Please fix. Reproducible: Always Steps to Reproduce: 1. Add sage-on-gentoo overlay 2. Install =dev-python/numpy-1.10.4 from the main Gentoo repository. 3. Run `equery meta numpy`, or `equery meta numpy::gentoo`, or `equery meta =dev-python/numpy-1.10.4::gentoo`. Actual Results: Output always comes from sage-on-gentoo overlay and looks like this: $ equery meta =dev-python/numpy-1.10.4::gentoo * dev-python/numpy [gentoo] Maintainer: francois.bissey@canterbury.ac.nz (Francois Bissey) Maintainer: sci@gentoo.org (Gentoo Science Project) Maintainer: python@gentoo.org (Python) Upstream: Remote-ID: numpy ID: pypi Homepage: http://www.numpy.org/ Location: /var/lib/layman/sage-on-gentoo/dev-python/numpy [...] Expected Results: At least `equery meta numpy::gentoo` and `equery meta =dev-python/numpy-1.10.4::gentoo` should give info from the main tree, not sage-on-gentoo overlay. Additionally the first line of the output is `* dev-python/numpy [gentoo]`, which adds to the overall confusion about what the output really describes.
Created attachment 431494 [details] emerge --info gentoolkit
Created attachment 431496 [details] dev-python/numpy/metadata.xml from the main tree
Created attachment 431498 [details] dev-python/numpy/metadata.xml from sage-on-gentoo overlay
Created attachment 431500 [details] /etc/portage/repos.conf/gentoo.conf
Created attachment 431502 [details] /etc/portage/repos.conf/layman.conf
Also it would be nice, if `equery meta` showed info respecting the repository of the installed package. In the example above I would expect `equery meta numpy` to show me info from the main tree, because I have it installed from there. But if I don't have numpy installed I would expect `equery meta numpy` to show info from the repository that would be used if I run `emerge numpy`. If I understand correctly that would be the repository with the most priority.
equery appears to be generally unaware of repository specifications in atom syntax. For instance, `equery which`: $ equery w gcc::gentoo /var/lib/layman/hardened-development/sys-devel/gcc/gcc-6.1.0.ebuild I don't think priorities should work as you've described though. I would expect any equery subcommand to resolve packages according to your repos.conf priorities unless a specific repo is given by the atom - in the same manner as a package atom given to `emerge` or `ebuild`. You would normally expect `gentoo` as a `main-repo` to be masked because its priority is `-1000` by default.
Also it looks like while equery does respect PORTAGE_REPOSITORIES, PORTAGE_REPOSITORIES completely replaces any repos.conf configuration instead of cascading from the parent configuration and overriding just the specified values. ~ $ PORTAGE_REPOSITORIES=$'[gentoo]\npriority = 9999' equery w gcc !!! Section 'gentoo' in repos.conf is missing location attribute !!! Section 'gentoo' in repos.conf is missing location attribute !!! No packages matching 'gcc' ~ $ PORTAGE_REPOSITORIES=$'[gentoo]\nlocation = /usr/portage\npriority = 9999' equery w gcc /usr/portage/sys-devel/gcc/gcc-5.3.0.ebuild ~ $ PORTAGE_REPOSITORIES=$'[gentoo]\nlocation = /usr/portage\npriority = -9999' equery w gcc /usr/portage/sys-devel/gcc/gcc-5.3.0.ebuild ~ $ pquery --attr repo --attr path --max sys-devel/gcc::{gentoo,hardened-development} sys-devel/gcc-6.1.0 repo="hardened-development" path="/var/lib/layman/hardened-development/sys-devel/gcc/gcc-6.1.0.ebuild" sys-devel/gcc-5.3.0 repo="gentoo" path="/usr/portage/sys-devel/gcc/gcc-5.3.0.ebuild" So PORTAGE_REPOSITORIES is pretty much useless for convenient interactive use unless you want to reproduce the entire configuration in the variable. Granted I don't know whether that's the intended purpose of PORTAGE_REPOSITORIES. The manual has one sentence about it.
(In reply to Dan Douglas from comment #7) > I don't think priorities should work as you've described though. I would > expect any equery subcommand to resolve packages according to your > repos.conf priorities unless a specific repo is given by the atom - in the > same manner as a package atom given to `emerge` or `ebuild`. You would > normally expect `gentoo` as a `main-repo` to be masked because its priority > is `-1000` by default. Well, if a package isn't installed, then yes. However if a package is already installed, then why would one care about info about a package that isn't installed and possibly coming from a different repo? With some luck it could be a completely unrelated package with the same name. I usually don't care about `equery meta` until I am filing bugs and when this happens it would be nice to have relevant info without an additional pain of remembering/querying where each package was installed from.
(In reply to Coacher from comment #9) > (In reply to Dan Douglas from comment #7) > > I don't think priorities should work as you've described though. I would > > expect any equery subcommand to resolve packages according to your > > repos.conf priorities unless a specific repo is given by the atom - in the > > same manner as a package atom given to `emerge` or `ebuild`. You would > > normally expect `gentoo` as a `main-repo` to be masked because its priority > > is `-1000` by default. > Well, if a package isn't installed, then yes. > > However if a package is already installed, then why would one care about > info about a package that isn't installed and possibly coming from a > different repo? With some luck it could be a completely unrelated package > with the same name. I care when using equery in a script or in conjunction with another tool in which I would like a package to be resolved in the same manner portage would. For example if you want to run a particular phase for a package you're working on in an overlay but isn't yet installed, I often use something like `ebuild "$(equery w pkgname)" clean configure`. It would be rather annoying and possibly dangerous if it were inconsistent. > I usually don't care about `equery meta` until I am filing bugs and when > this happens it would be nice to have relevant info without an additional > pain of remembering/querying where each package was installed from. If you wanted something else you WOULD be able to specify it if equery supported doing so in the first place. Since I posted I found this is apparently a known issue and there's a GSOC project to create a portable C library for atom resolution which can be shared among various tools. I assume equery is one of the tools that's affected. I was going to mention though there are times I'd like different defaults. The most annoying IMO is ambiguous categories. Haskell packages are notoriously bad because the package names come from the upstream hackage name, and haskell bindings for libraries in categories outside dev-haskell almost always conflict, and equery throws an error when referring to such a package, even when the haskell binding isn't installed and the other package doesn't depend on it. I don't think that should be the default though.
I guess I'm observing the same behavior when listing keywords, which I guess means this behavior extends to the entirety of equery? $ equery y -O mixxx Keywords for media-sound/mixxx: | | u | | a a a n p r s | n | | l m r h i m m i p i s p | u s | r | p d a m p a 6 i o p c s 3 a x | s l | e | h 6 r 6 p 6 8 p s p 6 c 9 s r 8 | e o | p | a 4 m 4 a 4 k s 2 c 4 v 0 h c 6 | d t | o -------------+---------------------------------+-----+--------- 1.10.1 | o + o o o o o o o o o o o o o + | o 0 | gentoo 1.11.0 | o ~ o o o o o o o o o o o o o ~ | # | gentoo 1.11.0 | o ~ o o o o o o o o o o o o o ~ | # | proaudio 1.11.9999 | o o o o o o o o o o o o o o o o | # | proaudio 2.0.0 | o ~ o o o o o o o o o o o o o ~ | # | proaudio [I]2.0.0-r1 | o ~ o o o o o o o o o o o o o ~ | # | gentoo [I]2.0.0-r1 | o ~ o o o o o o o o o o o o o ~ | o | sabayon 9999 | o o o o o o o o o o o o o o o o | o | proaudio It shows [I] for installed 2 times, the first one from gentoo (that one is actually installed) and one from an overlay that also provides the same version which isn't installed.
