Bugzilla Bug 14178

hi!
just found out about an annoying circular dep between qt-3.1.0 and unixODBC

anyone knowing a solution? (besides emerging one of them w/o the other first and
then again..)

greetings

this works:

USE='-odbc' emerge qt && emerge unixODBC && emerge qt

Well since these are real circular deps, i.e. each of them needs the other at
build time for the 
added functionality, I don't see what we can do :-( 
Maybe some of those new portage features could help. I'm not sure what exactly
is done 
already and what is planned. carpaski, what would the right way of doing this
be? 

In that case it would be nice to stop the emerge of qt right in the beginning
if the odbc is not merged and it is included in use flags...

I just lost two hours of compiling... :+(

Based on the lengths of the compiles of unixODBC and Qt, might it not be better
do it the other way around?
USE='-qt' emerge unixODBC && emerge qt && emerge unixODBC 

As unixODBC only needs qt for its text mode utilities we could have unixODBC
check on the presence of qt, and depend on qt only then. Or have some
"bootstrap" version that gets masked on whether or not qt is in the use flags
and whether or not is installed

I feel the correct solution is would have the effect as:
USE="-qt" emerge unixODBC
USE="odbc" emerge qt
USE="qt" emerge unixODBC

this would take big advantage of ccache, so the second build should go fairly fast.

Hi, perhaps a check on use qt && use odbc and then emit a warning/error if
the missing dep is not yet installed. This would make it a lot easier for
users to work around this circular dep.

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

Im adding this stuff in here since someone thinks my bug is a duplicate of
this one.  I dont happen to agree, since this isnt really a bug at all, its
WAD (working as designed) with enhancements planned.

right now, there is no circular dependency since unixODBC has a dependency
of qt-2.3.2-r1 when kde depends on qt-2.3.2-r4.

My bug/concern/gripe is that the depend info on kde was updated without checking
on the other packages to see if they could depend on the new version of qt
or not.

I need unixODBC to depend on the SAME verion of qt as kde does so that the
instructions in this bug about dealing with the circular dependency actually
work.

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

Check out Bug 35875.

The circular dependancy appears to have been corrected when starting from the one of the two coupled ebuilds.

"emerge -v unixODBC" fails due to the missing odbc include files for the qt build that happens first.

"emerge -v qt" builds okay, even though unixODBC is built before building qt.

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

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

portage should recognize and at least warn about circular dependecies

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

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

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

The solution is to have a separate ebuild for the qt odbc plugin. I've
committed a package.masked dev-db/qt-unixODBC ebuild that does this, please
test. (It will of course overwrite the plugin as installed by x11-libs/qt,
so be careful.)
If we accept this, qt would have PDEPEND="odbc? ( dev-db/qt-unixODBC )" and
unixODBC could then DEPEND on qt without creating a circular dep.
I haven't tested actually tested the result of this ebuild because I don't
have/use unixODBC, but the principle should be sound :-) 
Redhat btw has separate rpms for the qt odbc plugin -and- for the odbc qt gui.

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

Will someone please test this so it can be unmasked? I see lots of people CCd,
so please, someone help. And/or suggest a stock program using qt database
plugins I can use for testing without preparing a database myself.

rphillips: as the unixODBC guy, could you please test this?

I emerged dev-db/qt-unixODBC. Everything compiled and installed OK.
But the libodbcinstQ.* libs are missing. They are necessary for the GUI configurator /usr/bin/ODBCConfig.

libodbcinstQ is built by the unixODBC package, not by qt.

Anyway, libodbcinstQ has to do with the QT GUI for ODBCConfig. AFAIK it has
nothing to do with the qt odbc plugin.

Is ODBCConfig at all relevant to the qt odbc plugin? AFAICS, it configures
unixODBC itself, while the QT unixODBC plugin allows access to uixODBC.

unixODBC good be devided into 2 parts:
- one ebuild for the unixODBC libraries
- one ebuild for the unixODBC GUI-tools

qt could than depend on the unixODBC libraryies only, while the unixODBC GUI-tools can depend on qt without creating a circular dep.

True. I'm just as fine with that, but it'll have to be some unixODBC guy
who'll do it, not me.

It seems noone's going to bother to test my solution. If this continues I'll
reassign the bug to the unixodbc and tell them to either test and unmask my
solution or roll their own as per your comment.

Ohh, sorry. I see you suggested a seperat ebuild for unixODBC's GUI already in
comment #18. Well, i will test this soon.

Ohh, you didn't separate the unixODBC GUI from unixODBC's core libraries, but
qt's ODBC-plugins from the main qt build - well, what do the others think?

a) devide unixODBC ebuild into 2: one for the unixODBC libraries, one for the
GUI
b) build qt's ODBC plugin separatly 

my vote goes for a)

P.S.: i haven't tested the qt-unixODBC ebuild yet :-(

I vote for having both.
- 99+% of QT users don't have need of ODBC
- most ODBC users don't use/need any GUI (I certainly don't).

Sven wrote :
P.S.: i haven't tested the qt-unixODBC ebuild yet :-(

I reported the folowing bugs:
I'm using a GENTOO 2.6.9_r9 kernel with Kdevelop 3.1.0 using KDE 3.3.1, qt 
3.3.3, g++ 3.3.

Sven wrote :
P.S.: i haven't tested the qt-unixODBC ebuild yet :-(

I reported the folowing bugs:
I'm using a GENTOO 2.6.9_r9 kernel with Kdevelop 3.1.0 using KDE 3.3.1, qt 
3.3.3, g++ 3.3.

 1/
 I'm able to set up a database connection using qt designer, but when I add
one of the data aware widgets (dataview, datatable, databrowser) the tables 
do not show up. I'm able to connect to my SQLServer database with all of 
the odbc test tools, sqsh 
Setup:

QODBC3
unixODBC

I did a snif between the client and the server:
- Upon the 'connect', the client logs on and requests a list of table 
available in the database 'sp_tables @ table_type='TABLE ','VIEW'
- The server starts responding with all tables.
- After that, the client sends a 'cancel packet' (tds type 0x06) to the 
server.
- After that the client sends query packets with 'sp_columns'. The query 
should be 'sp_columns @tablename=tablename' 
- The server replies with the error message that it expected a tablename with 
the 
'sp_columns' procedure, wich was not supplied ...

There are probably as much of these requests sent as there are tables in the 
database (since the database contains much tables, I did not count to 
verify).


2/
I'm not able to get the data from a text field from a table on a SQL server.
here's some code:

            QSqlQuery query;
            query.setForwardOnly( TRUE );
            query.exec( "SELECT * FROM Table" );
     if ( query.isActive() ) {
                while ( query.next() ) {
                     result->append(query.value(0).toString() + ", " + 
                     query.value(1).toString()  + ", " + 
query.value(2).toString()  + ", 
" + query.value(4).toString()  + ", " + query.value(4).toString()  + ", " + 
query.value(5).toString() + "\n");
       
                }
            }

query.value(1) and query.value(3) should be filled with text, but the result 
is empty. The others are numbers and contain the correct data. I also get the 
folowing error messages:
qGetStringData: Error while fetching data (-1)

Upon further searching I found that query.value(1).toString().isNull() results 
in TRUE

In short, textfields from the database are not retrieved.

When using sqsh, I do see all data correctly.

If the odbc people take this off my back it's fine by me.
Matthias: are you talking about qt-unixODBC? If so does the plugin from
the current qt ebuild work for you?

I have installed this version of qt-unixODBC:
*  dev-db/qt-unixODBC [ Masked ]
      Latest version available: 3.3.3
      Latest version installed: 3.3.3
      Size of downloaded files: 14,086 kB
      Homepage:    http://www.trolltech.com/
      Description: QT version 3.3.3
      License:     || ( QPL-1.0 GPL-2 )
Before that, I was not able to connect to the server.

And does the monolithic ebuild (ie USE=odbc emerge qt) work any better?
If not then it's unrelated to the issue of separating the plugin;
please open a separate bugreport.

I re-emerged QT: same problems ...
Sorry for confusing the subject.

Ok, guys, I'm not a noob but definitely not a pro either so you can safely
disregard this but just as an idea:
If unixODBS build ok without qt installed even if qt is in its USE flags than
why not just change the dependency from DEPEND ot RDEPEND or PDEPEND. My guess
is that in this way they would be merged in the right order. Still the ideas of
separating the packages look better to me but require more work of course.

MindEraser, that won't work. This is a true circular dep: each package
requires the other one to be built before it.

...Will someone test this properly, or split off the unixODBC qt GUI instead?
Much more of this and I'll decide noone actually uses this stuff and disable
the unixODBC support in QT entirely :-/

Since noone else cares about testing this apparently, I'm unmasking this.   
As far as I can determine it works (at least as well as the plugin worked when  
built by the qt ebuild).  
  
Archs: to summarize, the QT unixODBC plugin has been moved to a separate ebuild  
dev-db/qt-unixODBC to fix a circular dep between qt and unixODBC when both qt  
and odbc are in USE.  
I'm CCing you to let you know I added all your ~ keywords to qt-unixODBC, on 
the basis of the fact that the QT ebuild had them and this is just a 
refactoring (and I couldn't get anyone to test it, which to me means very few 
people use it). Thus I didn't want to make a new QT ebuild revision (and I 
couldn't make a dep in qt-unixODBC anyway that would say >=qt-3.3.4-r6 and 
~qt-3.3.4 at the same time...)  

stable on ppc64