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.
