Re: [trinity-devel] tdebinding (libsmoketqt) conflicts with libtqt-perl (libsmoketqt) - which is correct?
Can someone confirm which package is supposed to provide libsmoke. Currently I have libtqt-perl providing:
opt/trinity/bin/puic opt/trinity/lib/libsmoketqt.so opt/trinity/lib/libsmoketqt.la opt/trinity/lib/libsmoketqt.so.1.2.1 opt/trinity/lib/libsmoketqt.so.1
tdebindings (which finally built!) also provides:
opt/trinity/lib/libsmoketqt.so opt/trinity/lib/libsmoketqt.la opt/trinity/lib/libsmoketde.so.1 opt/trinity/lib/libsmoketde.so
Which package should provide libsmoketqt?
I always thought the answer is either. When tdebindings is built and installed with libsmoke support, then libtqt-perl is not supposed to build libsmoke. When tdebindings is not installed or built without libsmoke support, then libtqt-perl is supposed to build its own libsmoke.
I always build tdebindings before libtqt-perl.
But what do I know?
Darrell
On 01/28/2014 11:28 AM, Darrell Anderson wrote:
I always thought the answer is either. When tdebindings is built and installed with libsmoke support, then libtqt-perl is not supposed to build libsmoke. When tdebindings is not installed or built without libsmoke support, then libtqt-perl is supposed to build its own libsmoke.
I always build tdebindings before libtqt-perl.
Let's start with the last part first:
But what do I know?
--> A lot!, that's why we are renaming the 'trinity-devel' list to the 'darrell-anderson' list...
Now on to the more pressing matter -- how to control:
if libsmoke from A, then no libsmoke from B elif libsmoke from B, then no libsmoke from A fi
Is this purely a packaging matter, of should there be some TDE logic that does this in the autotool/automake setup.
Right now libtqt-perl is a prime example of the hell we will find ourselves in when automake 2 arrives. It does not build with automake 1.14 without significant hacks. Slavek has taken an initial patch of the problem and created an update to libtqt-perl and it looks like he has set libsmoke to build only in tdebinding. See:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1875#c5
So that it the way we will go.
On Tuesday 28 of January 2014 21:56:56 David C. Rankin wrote:
A lot!, that's why we are renaming the 'trinity-devel' list to the 'darrell-anderson' list...
Now on to the more pressing matter -- how to control:
if libsmoke from A, then no libsmoke from B elif libsmoke from B, then no libsmoke from A fi
Is this purely a packaging matter, of should there be some TDE logic that does this in the autotool/automake setup.
Right now libtqt-perl is a prime example of the hell we will find ourselves in when automake 2 arrives. It does not build with automake 1.14 without significant hacks. Slavek has taken an initial patch of the problem and created an update to libtqt-perl and it looks like he has set libsmoke to build only in tdebinding. See:
I understand that in libtqt-perl is a "copy" of kalyptus and smoke from the tdebindings. In fact, as a "third-party" for cases that are not yet available in the system. As you can see, this copy not been updated to reflect changes in tdebindings. Update kalyptus been addressed until now, when the problem occurred.
I would venture to say that the "right place" for libtqt-perl would include it as another part of tdebindings.
Slavek --
On 01/28/2014 06:40 PM, Slávek Banko wrote:
I would venture to say that the "right place" for libtqt-perl would include it as another part of tdebindings.
Slavek
Ok, we will rename 'trinity-devel' to 'Darrell&Slávek'@lists.pearsoncompting.net....
Slavek, I think you are 100% correct. If you can do it, run it by Tim, but I see no reason to have both packages building the same libraries. I say do it.
-
Darrell Anderson -
David C. Rankin -
Slávek Banko