Looks like more people is trying to migrate /bin/sh away from bash to other shells (usually dash, but I have also seen people using tcsh) I think would be interesting to show the /bin/sh provider in emerge --info then (ideally, it could also show the package and version that is used for that provider as looks like different dash versions behave differently on regard of the compat they provide with bash (bug 527644)) Thanks a lot
(In reply to Pacho Ramos from comment #0) > I think would be interesting to show the /bin/sh provider in emerge --info > then (ideally, it could also show the package and version that is used for > that provider as looks like different dash versions behave differently on > regard of the compat they provide with bash (bug 527644)) Thanks to indexing, performance of the vardbapi._owners.iter_owners method should be good enough to query the package that owns the file that /bin/sh references. Alternatively, we could simply parse the output of '/bin/sh --version'.
Created attachment 390424 [details] first-owner.py: benchmark time taken to locate an owner of a file This script can be used to gauge the performance impact of locating an owner of a file. Example usage: time first-owner.py /bin/bash With ~2500 installed packages, real time is about 2.5 seconds on one of my computers with Core i5-2400S. On another computer with the same installed packages but with Core i3-3217U, real time is about 4.8 seconds. Both measurements are with hot cache. Based on this measurements, I think maybe we should simply parse the output of '/bin/sh --version'.
It seems that dash does not have a --version option. I guess we can use a simple mapping like /bin/sh -> name -> app-shells/${name} to query the version.
(In reply to Zac Medico from comment #3) > It seems that dash does not have a --version option. I guess we can use a > simple mapping like /bin/sh -> name -> app-shells/${name} to query the > version. Maybe it should try to look at app-shells on a first try... but I am unsure if all shell providers are there. Doesn't busybox (on sys-apps) also provide a shell? But, maybe it would be enough to look for app-shells/ stuff and, if not found, simply show a warning in the output that would lead us to ask the reporter about it :/ If we would have some virtual/sh package listing the known providers maybe would be easier as would only need to look for that list of providers instead of all the tree, but looks like we don't have that virtual (probably because the alternatives are still not drop-in replacements)
(In reply to Pacho Ramos from comment #4) > Maybe it should try to look at app-shells on a first try... but I am unsure > if all shell providers are there. Doesn't busybox (on sys-apps) also provide > a shell? Yeah. I guess we could have it just search for any package with the same name as the symlink target, and if there are matches from multiple categories, then prefer app-shells.
I have a patch in this branch: https://github.com/zmedico/portage/commits/bug_527996
Thanks What will it do if both fail? I would simply show a warning (for example, I think some people has "bb" (from busybox?) as /bin/sh provider
(In reply to Pacho Ramos from comment #7) > What will it do if both fail? I would simply show a warning (for example, I > think some people has "bb" (from busybox?) as /bin/sh provider Is will say "sh bb" if it can't locate a package named bb.
OK :)
I've posted a patch for review here: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/4846
Actually, bb properly map to sys-apps/busybox because bb is a symlink to busybox, and my patch uses os.path.realpath() to resolve symlinks recursively. I will update comments in the patch to note this.
This is in the master branch: https://github.com/gentoo/portage/commit/226b398c0549d5815f81921ba35fe8ff9d02052d
This is in the portage-2.2.15 release.
