On 06/20/2012 12:15 PM, Darrell Anderson wrote:

Which package is pinentry built?

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.

On 06/20/2012 12:29 PM, Calvin Morrison wrote:

You could spoof it with a symlink as a temporary solution.

Calvin

I just copied the PKGBUILD from ABS and did the --enable-pinentry-qt thing :)

On 06/20/2012 12:53 PM, Darrell Anderson wrote:

Which package? I grepped the entire source tree and found no such configure option:

grep -rn "enable-pinentry-qt" .

So which package do you add that configure option?

Darrell

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 :)

...

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 :)

Ok, I follow. I'm slow. :-)

I have pinentry installed. Of course, built against Qt4 rather than (T)Qt3.

Perhaps that package needs to be rebuilt, explicitly declaring enable-pinentry-qt if the package was built against Qt4. When that option is used, you need to use the standard "qt-dir" options to ensure the configuration knows where to find TQt3:

--with-qt-dir=${QTDIR} \ --with-qt-includes=${QT_INCLUDE_DIR} \ --with-qt-libraries=${QT_LIB_DIR} \

Will the build still fail because moc was renamed to tqmoc? After a quick look at the pinentry sources, yes: the configure script explicitly looks for moc. I'm thinking a patch to change moc->tqmoc, much like we just patched all of the Trinity sources with the new names.

Would a sym link moc->tqmoc succeed? Probably, but only when the TQt3 bin files are installed to a location different from the Qt4 bin files and the "qt-dir" configure options are used to explicitly find TQt3. Using a sym link would be a packaging issue.

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

I see the logic. My pinentry rebuild was trivial due to building on 3.5.12 with Qt3. Bottom line is all Qt3 reliant apps outside the TDE tree will need renaming to build against TQt3. Darrell - no, I have no list. It was really just a quirk that the question popped into my head. After it popped -- my thought was (a) how would a system install without dragging in Qt4 dependencies if the package being installed had a Qt dependency but found no q_whatever file? and (b) how big is the list of files affected?

I think from a practical standpoint we will just have to see which apps provide the dependency and go from there. While there may be no choice when faced with a favorite apps that only builds on Qt4 (there is a choice to install it or not), the desktop shouldn't force that choice.

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.

After the TQt3 renaming, will it be possible to rebuild TQt3 & TDE with Qt4 installed.

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:

...

After the TQt3 renaming, will it be possible to rebuild TQt3 & TDE with Qt4 installed.

That is the intent, and also one of the main reasons for the existence of TQt3 vs. the original unmodified Qt3.

Tim

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?

On 06/21/2012 03:16 PM, Timothy Pearson wrote:

No, unless they have already been modified to use tqtinterface (which is unlikely).

Tim

Hmm.. In other words -- no need to provide the old links :)

...

We probably should have some notes about unique non

Trinity packages that need such attention. Do

...

you know of other packages outside of KDE3/Trinity that

build against the old Qt3 and are expected to

...

work within Trinity? For example, the old version of

QCAD built against Qt3, but was not a KDE3 app.

Gentoo's kde-sunset overlay contains on the order of a hundred applications that aren't part of KDE3 proper, and aren't currently part of the Trinity project, but must have had/needed KDE3 or QT3 support or they wouldn't have been exiled to that overlay in the first place. I don't know how many of them have QT4 replacements, as many of them I'd never heard of before I poked into the files this afternoon. I also don't know how many of them are wanted/useful or need tweaking to build for us.

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:

Which package? I grepped the entire source tree and found no such configure option:

grep -rn "enable-pinentry-qt" .

So which package do you add that configure option?

Darrell

Oops forgot the link:

ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.8.1.tar.gz