Bugzilla Bug 88454

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 an attachment (id=55747) [details]
surfraw-bump_2-0-2.patch

Created an attachment (id=55748) [details]
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 an attachment (id=55767) [details]
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 an attachment (id=56042) [details]
surfraw-bump_2-0-2.patch

Created an attachment (id=56043) [details]
surfraw-2.0.2-bbc_new_url.patch

For $FILESDIR see comment #6 for reason.

Created an attachment (id=56045) [details]
surfraw-2.0.2-gentoo_pkg_tools.patch

For $FILESDIR see comment #6 for reason.

Created an attachment (id=56046) [details]
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.