Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 580794 - app-portage/gentoolkit: info from overlays always shadows info from the main repo in `equery meta` output
Summary: app-portage/gentoolkit: info from overlays always shadows info from the main ...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Tools (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage Tools Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-22 03:32 UTC by Coacher
Modified: 2016-09-08 18:56 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info gentoolkit (info,6.72 KB, text/plain)
2016-04-22 03:33 UTC, Coacher
Details
dev-python/numpy/metadata.xml from the main tree (metadata.xml,876 bytes, application/xml)
2016-04-22 03:35 UTC, Coacher
Details
dev-python/numpy/metadata.xml from sage-on-gentoo overlay (metadata.xml,1000 bytes, application/xml)
2016-04-22 03:36 UTC, Coacher
Details
/etc/portage/repos.conf/gentoo.conf (gentoo.conf,130 bytes, text/plain)
2016-04-22 03:37 UTC, Coacher
Details
/etc/portage/repos.conf/layman.conf (layman.conf,434 bytes, text/plain)
2016-04-22 03:38 UTC, Coacher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Coacher 2016-04-22 03:32:39 UTC
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.
Comment 1 Coacher 2016-04-22 03:33:30 UTC
Created attachment 431494 [details]
emerge --info gentoolkit
Comment 2 Coacher 2016-04-22 03:35:04 UTC
Created attachment 431496 [details]
dev-python/numpy/metadata.xml from the main tree
Comment 3 Coacher 2016-04-22 03:36:04 UTC
Created attachment 431498 [details]
dev-python/numpy/metadata.xml from sage-on-gentoo overlay
Comment 4 Coacher 2016-04-22 03:37:25 UTC
Created attachment 431500 [details]
/etc/portage/repos.conf/gentoo.conf
Comment 5 Coacher 2016-04-22 03:38:02 UTC
Created attachment 431502 [details]
/etc/portage/repos.conf/layman.conf
Comment 6 Coacher 2016-04-22 03:49:38 UTC
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.
Comment 7 Dan Douglas 2016-05-05 03:34:31 UTC
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.
Comment 8 Dan Douglas 2016-05-05 04:49:48 UTC
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.
Comment 9 Coacher 2016-05-08 05:33:21 UTC
(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.
Comment 10 Dan Douglas 2016-05-09 09:26:26 UTC
(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.
Comment 11 Simon 2016-09-08 18:56:49 UTC
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.