Re: [trinity-devel] tdebinding (libsmoketqt) conflicts with libtqt-perl (libsmoketqt) - which is correct?
28 Jan
2014
28 Jan
'14
9:28 a.m.
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
28 Jan
28 Jan
12:56 p.m.
New subject: [trinity-devel] tdebinding (libsmoketqt) conflicts with libtqt-perl (libsmoketqt) - which is correct?
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.
--
David C. Rankin, J.D.,P.E.
4:40 p.m.
New subject: [trinity-devel] tdebinding (libsmoketqt) conflicts with libtqt-perl (libsmoketqt) - which is correct?
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
--
6:42 p.m.
New subject: [trinity-devel] tdebinding (libsmoketqt) conflicts with libtqt-perl (libsmoketqt) - which is correct?
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'(a)lists.pearsoncompting.netcompting.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.
--
David C. Rankin, J.D.,P.E.
3764
days inactive
3765
days old
3 comments
3 participants
participants (3)
-
Darrell Anderson -
David C. Rankin -
Slávek Banko