On 06/20/2012 12:15 PM, Darrell Anderson wrote: It's a gpg dependency. It provides the widget for PIN entry communications. Currently it is built from pinentry-0.8.1. If you don't --enable-pinentry-qt, if your distro provides it with --enable-pinentry-qt4, I don't want to drag in all the Qt4 runtime for some odd thing like that. -- David C. Rankin, J.D.,P.E.

On 06/20/2012 12:29 PM, Calvin Morrison wrote: I just copied the PKGBUILD from ABS and did the --enable-pinentry-qt thing :) -- David C. Rankin, J.D.,P.E.

On 06/20/2012 12:53 PM, Darrell Anderson wrote: Yikes Darrell, It is not a TDE package.. Sorry, it is one of the system dependencies for gpg/gpg-agent. The package name is 'pinentry'. I'm sure it is on your box as we speak. That is what brought up my concern. "Will this renaming break all packages that are NOT tde packages but that rely on Qt?" If I understand your earlier response, the qmake paths/properties will handle outside packages that look for the Qt executables and find them under their new names. I don't know how that works, but I guess there is a pkgconfig type lookup or config file that would do it. Where I'm still lost is if there is both Qt4 and TQt3 installed and some package looks for the old Qt name -- how is it prevented from grabbing the Qt4 provided package by mistake? pinentry was just the example I stumbled across today. In the (tde-world, non-tde-world), it is the non-tde-world apps that concerned me regarding the name change. May not be an issue, but all the work you are having to do in the 'tde-world' having to be duplicated for all 'non-tde-world' Qt packages was what scared me :) -- David C. Rankin, J.D.,P.E.

One interesting item of note is that it should be theoretically possible to install both Qt3 and TQt3 on the same system. Programs written for Qt3 will NOT compile or run against TQt3, and (IMHO) should be ported to TQt3 (this can be done rather easily as only renaming, not rewriting, is required) if they do not have a Qt4 equivalent. Tim

Just about any choice we humans make eventually confronts the law of unintended consequences. Because all humans are and always will be creatures of limited knowledge, there is no way to avoid those results. Nobody can anticipate all reactions to any action we take. This is the natural structure of our lives (and why I don't embrace doctrines such as strict liability --- we don't live in a mechanized universe or in one with perfectly predictable certainties. But that is a topic for another forum and another day. :-) ). So here we have a great idea of renaming the TQt3 executables to avoid conflicts with Qt4. We then discover that certain Qt3 related non Trinity apps will be affected. To resolve the problem a sym link might be sufficient for many people, while others might be more comfortable with a package-specific moc->tqmoc patch. A long shot is to contact the package maintainers and ask them to explicitly support TQt3. They might do just that --- if we provide the patches. I don't know. Haven't yet tried. That would be a nice side effect: we could eliminate needing to explicitly specify the "with-qt*" configure options. You said pinentry is a gpg dependency. I don't knowingly use pinentry. Why does pinentry need to be built with GUI support? What are the benefits? Darrell

On 06/20/2012 08:37 PM, Timothy Pearson wrote: In the past we provided links to create 'tq....' functionality, what about reversing that logic to now create links to provide 'q....' functionality in the tqt3/bin dir? Seems logical -- will it work? Here is the old way Arch handled this and a new scheme based on the new names: make INSTALL_ROOT="$pkgdir" install <snip> # install link the apps provided by qt3 so we don't collide with # qt4 and can run them. # Old tqt links from before renaming # ln -sf "${_prefix}/bin/assistant" "${pkgdir}${_prefix}/bin/tqassistant" # ln -sf "${_prefix}/bin/designer" "${pkgdir}${_prefix}/bin/tqdesigner" # ln -sf "${_prefix}/bin/linguist" "${pkgdir}${_prefix}/bin/tqlinguist" # ln -sf "${_prefix}/bin/lrelease" "${pkgdir}${_prefix}/bin/tqlrelease" # ln -sf "${_prefix}/bin/lupdate" "${pkgdir}${_prefix}/bin/tqlupdate" # ln -sf "${_prefix}/bin/moc" "${pkgdir}${_prefix}/bin/tqmoc" # ln -sf "${_prefix}/bin/qmake" "${pkgdir}${_prefix}/bin/tqqmake" # ln -sf "${_prefix}/bin/qtconfig" "${pkgdir}${_prefix}/bin/tqtconfig" # New links providing old package functionality ln -sf "${_prefix}/bin/tqassistant" "${pkgdir}${_prefix}/bin/assistant" ln -sf "${_prefix}/bin/tqdesigner" "${pkgdir}${_prefix}/bin/designer" ln -sf "${_prefix}/bin/tqlinguist" "${pkgdir}${_prefix}/bin/linguist" ln -sf "${_prefix}/bin/tqlrelease" "${pkgdir}${_prefix}/bin/lrelease" ln -sf "${_prefix}/bin/tqlupdate" "${pkgdir}${_prefix}/bin/lupdate" ln -sf "${_prefix}/bin/tqmoc" "${pkgdir}${_prefix}/bin/moc" ln -sf "${_prefix}/bin/tqmake" "${pkgdir}${_prefix}/bin/qmake" ln -sf "${_prefix}/bin/tqtconfig" "${pkgdir}${_prefix}/bin/qtconfig" ln -sf "${_prefix}/bin/tquic" "${pkgdir}${_prefix}/bin/uic" Will packages that relied on Qt3 still build if they use the new TQt3 binaries? -- David C. Rankin, J.D.,P.E.

On 06/21/2012 03:16 PM, Timothy Pearson wrote: Hmm.. In other words -- no need to provide the old links :) -- David C. Rankin, J.D.,P.E.

Interesting. There is no nice list, but I found this: http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=tree Looks like about 50 to 60% of the apps are part of the original KDE3 or closely related (kaffeine, koffice, etc.), which we already support. I noticed others that were Qt3 dependent but not necessarily KDE3 dependent, such as QCAD. The list does contain pinentry, in the app-crypt collection, but isn't going to address the TQt3 bin file renaming. Darrell

On 06/20/2012 12:53 PM, Darrell Anderson wrote: Oops forgot the link: ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.8.1.tar.gz -- David C. Rankin, J.D.,P.E.