| Summary: | circular dep: qt3, unixODBC | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Thomas Raschbacher <lordvan> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alpha, altstadt, carpaski, hppa, ia64, lordvan, matthias.gallant, michael.postmann, mips, mmc, n1ywb, naknomik, pez, ppc, rance, robbat2, ronald, rphillips, sparc, sven.koehler, trelane |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 33440 | ||
| Bug Blocks: | |||
|
Description
Thomas Raschbacher
2003-01-19 07:49:28 UTC
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 |
