Closed iDarkTemplar closed 3 years ago
vaeth
commented
3 years ago 
iDarkTemplar
commented
3 years ago /etc/portage/package.accept_keywords/cross-x86_64-w64-mingw32:cross-x86_64-w64-mingw32/gdb amd64 ~amd64
/etc/portage/package.accept_keywords/cross-i686-w64-mingw32:cross-i686-w64-mingw32/gdb x86 ~x86 -amd64 -~amd64$ eix --print ARCH
amd64$ ls /var/db/repos/dt-overlay-crossdev/profiles
categories repo_name
$ for i in /var/db/repos/dt-overlay-crossdev/profiles/* ; do echo file $i ; cat $i ; done
file /var/db/repos/dt-overlay-crossdev/profiles/categories
cross-i686-w64-mingw32
cross-x86_64-w64-mingw32
file /var/db/repos/dt-overlay-crossdev/profiles/repo_name
dt-overlay-crossdevBtw, if you didn't try reproduce steps yet, crossdev just makes a symlink from ${CROSSDEV_OVERLAY}/${CROSS_TARGET}/${PACKAGE_NAME} to ${PORTAGE_REPO}/${PACKAGE_GROUP}/${PACKAGE_NAME}, i.e. in my case it created following structure (/usr/portage is location of gentoo repo):
$ LC_ALL=C ls -la /var/db/repos/dt-overlay-crossdev/cross-*
/var/db/repos/dt-overlay-crossdev/cross-i686-w64-mingw32:
total 8
drwxr-xr-x 2 root root 4096 Jul 21 09:17 .
drwxr-xr-x 7 root root 4096 Jul 21 09:17 ..
lrwxrwxrwx 1 root root 31 Jul 21 09:17 binutils -> /usr/portage/sys-devel/binutils
lrwxrwxrwx 1 root root 26 Jul 21 09:17 gcc -> /usr/portage/sys-devel/gcc
lrwxrwxrwx 1 root root 26 Jul 21 09:17 gdb -> /usr/portage/sys-devel/gdb
lrwxrwxrwx 1 root root 37 Jul 21 09:17 mingw64-runtime -> /usr/portage/dev-util/mingw64-runtime
/var/db/repos/dt-overlay-crossdev/cross-x86_64-w64-mingw32:
total 8
drwxr-xr-x 2 root root 4096 Jul 21 09:17 .
drwxr-xr-x 7 root root 4096 Jul 21 09:17 ..
lrwxrwxrwx 1 root root 31 Jul 21 09:17 binutils -> /usr/portage/sys-devel/binutils
lrwxrwxrwx 1 root root 26 Jul 21 09:17 gcc -> /usr/portage/sys-devel/gcc
lrwxrwxrwx 1 root root 26 Jul 21 09:17 gdb -> /usr/portage/sys-devel/gdb
lrwxrwxrwx 1 root root 37 Jul 21 09:17 mingw64-runtime -> /usr/portage/dev-util/mingw64-runtimeThus, gdb ebuilds are identical to those currently in gentoo tree.
vaeth
commented
3 years ago There is a misunderstanding for 2: I mean the keywords listed by eix -l ...
But I think I already know what is going on: It will list you for gdb
~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~ppc-aix ~x64-cygwin ~amd64-linux ~x86-linux ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
My analysis: You have presumably the default OVERLAY_CACHE_METHOD="parse|ebuild*" and do not have configured something else for this overlay. This means that the ebuild in the overlay is first parsed by some quick heuristic whcih gets the worng KEYWORDS - since it does get some keywords, there is no reason to conjecture something went bad, and therefore the much slower "ebuild*" cache method is not attempted.
Solution: You must either use cache method ebuild (or at least ebuild*) for the overlay or - better - use egencache and setup the overlay to only use metadata-md5.
For details, see the manpage of eix for cache method "parse" and the "SPEEDUP" section.
iDarkTemplar
commented
3 years ago Yep, regarding 2 there probably is a misunerstanding.
For me eix -l */gdb provides following output:
I see no keywords information in the output. Maybe it was added in newer version, one not yet marked stable in Gentoo.
And here's output of eix --print-all-keywords */gdb:
Doesn't seem useful to me either.
You might be right about OVERLAY_CACHE_METHOD. I didn't change any eix settings. And keywords are present in ebuild, and it looks like this:
if [[ ${PV} != 9999* ]] ; then
KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~ppc-aix ~x64-cygwin ~amd64-linux ~x86-linux ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
fiProbably it's detected, but condition isn't processed.
Anyway, if parse method is considered unreliable and generating and using cache should fix it, I guess this report may be closed. Thank you.
vaeth
commented
3 years ago Keywords with eix -l: My fault. You either have to use eix -vl or set VERSION_KEYWORDS_NORMAL=true. I have the latter in my /etc/portage/eixrc/40-defaults for so many years that I forgot that this behavior is not the default.
iDarkTemplar
commented
3 years ago vaeth
commented
3 years ago Seems like conjectured. So I am closing it as "works as intended" (I am aware that this is not nice, but the only clean solution for the parsing problem is to use egencache). The heuristic parsing is completely trivial: It does not even attempt to interpret things like "if" but just looks for variable assignments and picks the last one it sees...
iDarkTemplar
commented
3 years ago There is a workaround and it sounds good for me. Thank you again.
How to reproduce:
Result:
While main gdb package's 9999 version is properly displayed as unkeyworded, cross gdb packages' versions 9999 are displayed as testing and testing-keyworded, but it's not true:
eix version:
I'm not observing such behaviour for cross binutils or gcc packages, only gdb is affected in current case: