www-client/surfraw's cite command clashes with the cite command from app-text/html-xml-utils, initially I couldn't decide where to file the bug but after a little thought and seeing the obvious fix I'm sure it should be solved at surfraw's end. Judging by the ambiguity of the command names in surfraw I'm sure you will find many more naming collisions too, which makes the fix described below seem more correct if that is guess^wdeductive reasoning is true. Although I don't particulary like the idea as a general solution, a switch to the Debian branch of surfraw[1] will alleviate the collisions, support more search engines, and apparently be maintained! Hmm, now I come to think of it the most important feature could perhaps be the bash completion in Debian's branch ;) The first attached patch just switches to the Debian tree, there is one possible major problem; it changes the behaviour from the version currently in portage(single frontend command with "hidden" backends). It should also be noted that the Debian branch is specifically defined as in the Public Domain, so the license for the package has been changed in the ebuild too. There is also a second patch attached which although I believe is The Right Thing I'm not sure. It moves the backend scripts to /usr/share/surfraw/, as my reading of the FHS leads to me to believe the files can not be considered arch dependant enough to be in /usr/lib. YMMV, which is why it is just a secondary patch. 1. http://alioth.debian.org/projects/surfraw/ Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 55747 [details, diff] surfraw-bump_2-0-2.patch
Created attachment 55748 [details, diff] surfraw-std_compliant_paths.patch As I mentioned in the description /my/ reading of the FHS suggests that /usr/ share is a more appropriate location for the backend scripts.
James, this package is unmaintained in portage. Are you willing to be maintainer-by-proxy for it? If you shoot bugs, I'll commit your fixes.
I suppose that explains the lack of a metadata.xml then ;) And yes, imagining the other alternative is the package dying.
Created attachment 55767 [details, diff] surfraw-std_compliant_paths.patch Refresh of the [possible] FHS compliancy patch, so it catches the man page's and completions references to the /usr/lib directory.
This final version, attached next, takes in all the changes from above plus: * The scripts _are_ now in /usr/share, as per the FHS spec. The patching has been moved to src_unpack() though. * The bash completion completes on package names where appropriate, using a some what ugly method cribbed from the gentoo-bashcomp package. * A fix is applied which is already done upstream means BBC searches actually work, the breakage was due to a URI change on the Beeb's website. * A fix is applied which is already done upstream means rhyming word searches actually again, the breakage was due to the end of lycos' services. The patch changes the used server to rhymezone. * The usage examples are now correctly prefixes with the 'sr' command, this usage is a change from the previous package's method. A note is displayed if the user is upgrading from 1.0.7. * A small typo in the configuration example, which would result in silent errors for cut 'n' paste users has been fixed. As far as I'm aware there are no remaining issues with this ebuild, but it was a lot of hassle for a simple working version bump :/
Created attachment 56042 [details, diff] surfraw-bump_2-0-2.patch
Created attachment 56043 [details, diff] surfraw-2.0.2-bbc_new_url.patch For $FILESDIR see comment #6 for reason.
Created attachment 56045 [details, diff] surfraw-2.0.2-gentoo_pkg_tools.patch For $FILESDIR see comment #6 for reason.
Created attachment 56046 [details, diff] surfraw-2.0.2-rhyme_new_url.patch For $FILESDIR see comment #6 for reason.
thanks for all the time you spent on this James. It's all in portage now. The patches are in their own tarball. I modified your ebuild a bit, so that if/when debian comes up with 2.0.2-2 it's a simple rename of the ebuild, instead of tweaking that other variable in the ebuild.
