Please, visit the forum URL. You will see clear and colorfull logs. revdep-rebuild [...] WARNING *** This is a rewritten version of revdep-rebuild *** [...] [ 20% ] * broken /usr/bin/rpl (requires libXm.so.3) [...] * Assigning files to packages * !!! /usr/bin/rpl not owned by any package is broken !!! * -n -e /usr/bin/rpl -> (none) whereas: /usr/lib/gentoolkit/bin/revdep-rebuild [...] Checking dynamic linking consistency... broken /usr/bin/rpl (requires libXm.so.3) [...] Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot [...] =doublehp/rpl2-4.0.0_pre4 => This is a regression bug of the new revdeprebuild, versus the old one. Here is the reason of the problem: /usr/bin/rpl is held by home made ebuild in personnal overlay: root@moon_gen_2:~# equery b /usr/bin/rpl [ Searching for file(s) /usr/bin/rpl in *... ] doublehp/rpl2-4.0.0_pre4 (/usr/bin/rpl) root@moon_gen_2:~# emerge -vp rpl2 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] doublehp/rpl2-4.0.0_pre4 USE="doc gnuplot vim" 0 kB [1] Total: 1 package (1 reinstall), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /opt/doublehp/usr/portage root@moon_gen_2:~# Forum page show this more clearly.
Created attachment 143680 [details] /tmp/emerge--info
root@moon_gen_2:~# which revdep-rebuild /usr/bin/revdep-rebuild root@moon_gen_2:~# equery b /usr/bin/revdep-rebuild [ Searching for file(s) /usr/bin/revdep-rebuild in *... ] app-portage/gentoolkit-0.2.4_pre7 (/usr/bin/revdep-rebuild) root@moon_gen_2:~#
Erm, works perfectly fine here with tons of overlays. doublehp as a CATEGORY is highly fishy for starters...
(In reply to comment #3) > Erm, works perfectly fine here with tons of overlays. doublehp as a CATEGORY is > highly fishy for starters... > This did not sound incompatible with Gentoo standards from what I could read in tutorials, and, provides really efficient security against double identical ebuilds names.
What is the output of the following commands? # qfile -qvC /usr/bin/rpl # pquery --nocolor --owns="/usr/bin/rpl" Does adding doublehp to /etc/portage/categories affect this?
dhp@moon_gen_2:/tmp$ qfile -qvC /usr/bin/rpl dhp@moon_gen_2:/tmp$ pquery --nocolor --owns="/usr/bin/rpl" -bash: pquery: command not found dhp@moon_gen_2:/tmp$ cat /etc/portage/categories doublehp dhp@moon_gen_2:/tmp$ => was already in. On my box, bug will not be reproductible as is, since I already remerged RPL2 :) but, I think that mv /usr/lib/openmotif-2.3/libXm.so.4 /usr/lib/openmotif-2.3/libXm.so.4_arch may help trigger it again, if you see what I mean :) (and does after a short test)
(In reply to comment #6) > dhp@moon_gen_2:/tmp$ qfile -qvC /usr/bin/rpl > dhp@moon_gen_2:/tmp$ [...] OK, this is a bug in portage-utils then. Basically qfile expects all categories except virtuals/ to have a dash. Workarounds are to either only use categories with a dash in it or use --no-util=portage-utils. Fixes are for qfile to stop making this assumption or for revdep-rebuild to stop using it. PMS allows categories without dashes so I think this should be fixed.
I'm happy to follow a standard when it's written and approved by the community and council. But EAPI=0 is not even approved. So.. Yes portage-utils does expect currently that all CAT's have a '-' in it or be named virtual/ .. Pretty easy to change this behavior when it's time.
Thus PEBCAK, thus I renamed doublehp/rpl2 to doublehp-test/rpl2 removed doublehp/rpl2 installed doublehp-test/rpl2 ... works fine. If you dont want to fix this regression problem, I am ok to close this. mv /usr/lib/openmotif-2.3/libXm.so.4 /usr/lib/openmotif-2.3 /libXm.so.4_arch revdep-rebuild [...] * /usr/bin/rpl -> doublehp-test/rpl2 [...] mv /usr/lib/openmotif-2.3/libXm.so.4_arch /usr/lib/openmotif-2.3/libXm.so.4 Sounds nice to me. I accept this as PEBCAK. If you want to keep this open and maintain old behaviour, it's up to maints :)
Also please note revdep-rebuild uses qfile by default if it's installed, but it's not required. If you find that it doesn't work for some reason you can just disable qfile support by passing "-u portage-utils" arg to revdep-rebuild
Once we have an approved standard, we can revisit this bug to ensure that it works correctly
we should open a bug about eapi and append this kind of bugs on it... jakub are you willing to open it and assign such bugs as blocker to this bug (and other similar when they appear)?
(In reply to comment #12) > we should open a bug about eapi and append this kind of bugs on it... > jakub are you willing to open it and assign such bugs as blocker to this bug > (and other similar when they appear)? Well I don't exactly see how's this related to EAPI? Categories without hyphen have worked for ages with portage supposed they are properly listed in the profile's categories list -> EAPI=0. This apparently is a legal category name as portage accepts it, also per PMS. You want categories without hyphen banned, or are suggesting this is an apparent portage bug? If not, then it's already documented now. If maintainers refuse to fix similar bugs, then such tool unfortunately should not be used by default by other tools which are heavily relied on by portage users and are documented all around, such as revdep-rebuild.
(In reply to comment #12) > we should open a bug about eapi and append this kind of bugs on it... > jakub are you willing to open it and assign such bugs as blocker to this bug > (and other similar when they appear)? Naming rules aren't subject to EAPI anyway (as EAPI is limted to ebuild contents)
portage-utils support disabled until this is straightened out. $ svn commit -m "Disable portage-utils support until it is able to handle categories without a hyphen. Bug #210386" Sending revdep-rebuild/revdep-rebuild Transmitting file data . Committed revision 478.
'make category names accept any of the following chars. [A-Za-z0-9+_.-]' /var/cvsroot/gentoo-projects/portage-utils/libq/vdb_get_next_dir.c,v <-- libq/vdb_get_next_dir.c new revision: 1.3; previous revision: 1.2
I tried to understand this one: Has portage-tuils been updated to work with revdep-rebuild, and yet the possibility to (with a little change) use qfile in revdep-rebuild (which on my system could make a HUGE diffrence in time to run, just break Imagemagick and time it) has been removed?
(In reply to comment #17) > I tried to understand this one: > > Has portage-tuils been updated to work with revdep-rebuild, and yet the > possibility to (with a little change) use qfile in revdep-rebuild (which on my > system could make a HUGE diffrence in time to run, just break Imagemagick and > time it) has been removed? revdep-rebuild was updated to give the user the option of several utilities to use, but mostly because of this bug (see comment #15), support for qfile was subsequently removed. After that, IIRC, Paul discovered that on his system, a properly constructed find statement was faster than portage-utils, equery, or pkgcore. Unless someone can disprove that or otherwise describe why using just find is not optimal, the option to use alternative utilities will probably not come back.
(In reply to comment #18) > After that, IIRC, Paul discovered that on his system, a > properly constructed find statement was faster than portage-utils, equery, or > pkgcore. Unless someone can disprove that or otherwise describe why using just > find is not optimal, the option to use alternative utilities will probably not > come back. FWIW, the `portageq owners` command should be able to beat them all in >=portage-2.1.5.5 since portage now indexes contents to optimize owner lookups. However, the required versions of portage aren't marked stable yet.
Supoort for third party lookup tools was removed from revdep-rebuild for performance reasons. Nothing left to do on this bug.
