Bugzilla Bug 198388

Recently I moved Firebird out of /opt and it's not installed in /usr. It seems
that this causes a conflict for those using unixODBC. Which also has a generic
isql command line tool/utility.

Initial research on this shows that many database have a isql command line
utility. Although I am not sure how many of those, if any are packaged on
Gentoo. First I know is not, M$ SQL, but the others, Sybase, Oracle, etc. Might
get packaged if they aren't already.

It has been suggested to rename the firebird isql binary. Which might be a way
to go. But that requires a change in binary name from upstream, likely to throw
users off without documentation or etc. Much less changing anything hard coded
in firebird to use the new binary name.

On that same note, another option could be to put firebird binaries in subdirs.
But that will potentially cause path issues. As the paths are relative ones,
that I have some what hacked the hard coded values and prepended ../../../. So
the stuff can be split up, yet relative paths still work.

Really not sure which way I will proceed or etc. Likely either has potential
drawbacks. Of course we could do either with unixODBC as well. But then there
is still the potential for other RDBMS to provide isql as well.

It would be nice to be able to say and rest on the fact that Firebird's
codebase is one of the oldest ones wrt to RDBMS, going back to InterBase,
Groton DB, etc. So one might argue that isql belong to Firenbird/InterBase long
before others used the same name for their binaries.

An inverse argument might be that, for those decades it resided in /opt. That
it was recently moved out of /opt be me which created this problem.

Pee can surely stream in either direction, just hopefully not into the window.
No clue how I will proceed or etc. Filing bugs for others to comment on, open
up discussion, ideas, and etc.

I will likely go with majority, unless it goes against a strong gut feeling or
etc. But I prefer to avoid dictatorship when possible. That said we surely
can't please all, all the time. So likely some trade offs, one way or another.

(In reply to comment #0)
> It has been suggested to rename the firebird isql binary. Which might be a way
> to go. But that requires a change in binary name from upstream, likely to 
> throw users off without documentation or etc. Much less changing anything hard
> coded in firebird to use the new binary name.

FWIW, that's what Debian does, it ships it as isql-fb. Firebird itself doesn't
use isql, so nothing more than a rename and warning to the user in ebuild is
required.

(In reply to comment #1)
> 
> FWIW, that's what Debian does

While it's nice to know what the others are up to. We don't do everything the
way Debian does it. Or this would be Debian not Gentoo :)

> it ships it as isql-fb. Firebird itself doesn't
> use isql, so nothing more than a rename and warning to the user in ebuild is
> required.

For a half ass solution sure. But then firebirds own .msg files would report
error output and etc as isql vs isql-fb, or what ever it's renamed to.

I don't recall seeing patches for that in Debians patch set. That another dev
was trying to get me to blanket apply to our version of Firebird in bug 198388.

http://ftp.debian.org/debian/pool/main/f/firebird2.0/firebird2.0_2.0.1.12855.ds1-4.diff.gz

Upon direct review of the entire patch set. I determined only a few would apply
to gentoo. But they weren't used, those changes, minor ones, were incorporated
with.

So granted none of the Firebird binaries seem to call or use it. I still need
to address it in other means. Which I am taking into considering but would like
input from others. Outside of our present conversation.

But does look like renaming is a potential solution. But I really am more
curious how many users out there or etc use Firebird and unixODBC. If they are
using the two together, or etc. Because it could also be candidates for
blockers as well.

*** Bug 198611 has been marked as a duplicate of this bug. ***

After consideration and looking through the sources I will be renaming the
firbeird isql to fbsql ASAP. It will require a bit of patching to the sources,
mostly/entirely for the *.msg files. Errors and such when using fbsql, so it
doesn't report isql and throw off people or etc. Also might need to document it
somewhere as well aside from einfo.

I have taken this matter upstream. They aren't to excited about my plans to
rename the binary short of action by them. But that's likely to take some time,
and I can't necessarily wait for them. I would provide a link to the post, but
the sourceforge ml threading seems broken or something.

http://sourceforge.net/mailarchive/forum.php?forum_name=firebird-devel

It's still current now, but might expire, later on one can search for it under
fbsql. But that seems to return a subset. No clue what's up with sourceforge
mls, but their archive sucks :(

*** Bug 198910 has been marked as a duplicate of this bug. ***

ok, I have decided to go ahead and rename to fbsql. I am switching from using a
patch to sed for splitting up firebird and changing paths. I have already done
that, as well as adding some additional sed commands to change isql to fbsql in
firebird help files and etc. Things that reference isql, but so far nothing
invokes it directly.

So this will be fixed and addressed with next commit of 2.0.3 & 2.1.0. Will
comment and close bug when that has occurred.

isql renamed to fbsql. Fixed and committed to CVS, 2.0.3.*-r4 and 2.1.0.*r2.
Closing bug.