| Summary: | tdevelop-trinity should not depend on g++, tdelibs14-trinity-dev, and tqt3-apps-dev | ||
|---|---|---|---|
| Product: | TDE | Reporter: | mgb-trinity |
| Component: | non-core programs | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | bugwatch, kb9vqf, mgb-trinity, slavek.banko |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2014 | ||
|
Description
mgb-trinity
2014-11-21 15:03:11 CST
Hi Tim, If you have the time I would really like to know your thinking on this issue. If necessary I can probably fax a TDE CLA, clone the repository, and offer you a trivial patch before the R14 RC2 deadline ... but frankly that's a lot of work if you don't agree and that time could be better spent on testing. Thanks, --Mike (In reply to mgb-trinity from comment #1) > Hi Tim, > > If you have the time I would really like to know your thinking on this issue. > > If necessary I can probably fax a TDE CLA, clone the repository, and offer > you a trivial patch before the R14 RC2 deadline ... but frankly that's a lot > of work if you don't agree and that time could be better spent on testing. > > Thanks, > > --Mike This one snuck past me; sorry. No, tdevelop should not depend on those packages (but it should probably suggest them). I'll have to look through the repository to see if someone committed this dependency on purpose or if it just snuck in somehow. g++ and tdelibs14-trinity-dev came in commit 85b66a39. My impression is that such changes would be better directed at tde-devel-trinity rather than tdevelop-trinity. tde-devel-trinity already depends on tdelibs14-trinity-dev but g++ could be added.
tqt3-apps-dev appears to come from ${shlibs:Depends} so I started trying to rebuild tdevelop-trinity from source. However I ran into a build error:
cd /tmp/W/tdevelop-trinity-14.0.0-r372/obj-i486-linux-gnu/doc/kdevdesigner && /usr/bin/meinproc --check --cache index.cache.bz2 /tmp/W/tdevelop-trinity-14.0.0-r372/doc/kdevdesigner/index.docbook
index.docbook:20: parser error : Entity 'tde-authors' not defined
<author>&tde-authors;</author>
(plus several similar errors)
(1) Off the top of the head can you easily point me to the missing builddep?
(2) So now I'm seriously wondering whether I have the time to start testing TDE package rebuilds.
I'm pretty sure (but not certain) that the other part of the problem originates with tde-packaging commit 4d71fde2. The change from file names to file patterns causes shared libraries to be included in tqt3-apps-dev package where they should not be. Later when tdevelop-trinity is built it links to the shared libraries instead of the intended static libraries, which means a binary install of tdevelop-trinity brings in tqt3-apps-dev and with it more than sixty unnecessary -dev packages. Adding to R14 block list. Sorry I haven't been able to get to this yet; been busy squashing other irritating issues in preparation for RC2. Will get to this tomorrow if possible; it's quite late here. (In reply to mgb-trinity from comment #4) > I'm pretty sure (but not certain) that the other part of the problem > originates with tde-packaging commit 4d71fde2. > > The change from file names to file patterns causes shared libraries to be > included in tqt3-apps-dev package where they should not be. > > Later when tdevelop-trinity is built it links to the shared libraries > instead of the intended static libraries, which means a binary install of > tdevelop-trinity brings in tqt3-apps-dev and with it more than sixty > unnecessary -dev packages. I have fixed the tdevelop dependends/suggests fields in GIT hash ae5b2bf. With regard to the tqt3 packaging I'm not sure I want to be tinkering with shared vs. static libraries this close to release. I prefer the shared library model as it allows tqt3 to be fixed without requiring rebuilds of the other packages; what specifically is brought in as a new dependency as a result of the changes in GIT hash 4d71fde2? Thanks! tqt3-apps-dev is a devel package, derived from qt3-apps-dev. You will note the package names both end in -dev and the package descriptions both state:
| This package is intended for developers who want to develop applications
| using the additional static libraries that ship with the applications
| included with ...
tqt3-apps-dev is definitely not intended to contain shared libraries.
I do not yet know whether KDE3 kdevelop was designed to use static libraries or whether it was built using shared libraries from a different package. In part this is because I'm running into a lot of tqt FTBFS due to missing builddeps and in part because I suspect this software came from Ubuntu versions and I have a better handle on Debian versions. I am still trying but I cannot promise results.
//
> what specifically is brought in as a new dependency as a result of the changes in GIT hash 4d71fde2?
As the package won't rebuild from source I can't modify it and give you an exact answer. However a possibly incomplete list of hard dependencies, excluding recommendations, is as follows:
tqt3-apps-dev
comerr-dev krb5-multidev libaudio-dev libcups2-dev libexpat1-dev
libfontconfig1-dev libfreetype6-dev libgcrypt11-dev libgl1-mesa-dev
libglu1-mesa-dev libgnutls-dev libgnutls-openssl27 libgnutlsxx27
libgpg-error-dev libgssrpc4 libice-dev libjpeg8-dev libkadm5clnt-mit8
libkadm5srv-mit8 libkdb5-6 libkrb5-dev liblcms1-dev libmng-dev
libp11-kit-dev libpng12-dev libpthread-stubs0 libpthread-stubs0-dev
libsm-dev libtasn1-3-dev libtqt3-headers libtqt3-mt-dev libx11-dev
libxau-dev libxcb1-dev libxcursor-dev libxdmcp-dev libxext-dev libxfixes-dev
libxft-dev libxi-dev libxinerama-dev libxmu-dev libxmu-headers libxrandr-dev
libxrender-dev libxt-dev mesa-common-dev tqt3-dev-tools uuid-dev
x11proto-core-dev x11proto-fixes-dev x11proto-input-dev x11proto-kb-dev
x11proto-randr-dev x11proto-render-dev x11proto-xext-dev
x11proto-xinerama-dev xorg-sgml-doctools xtrans-dev zlib1g-dev
(In reply to mgb-trinity from comment #3) > (1) Off the top of the head can you easily point me to the missing builddep? Honestly when developing on Debian and Ubuntu I allow apt to manage dependencies with apt-get build-dep <package name>. This, combined with dpkg-buildpackage -rfakeroot, has never lead to a FTBFS result like the one you posted above. Are you sure you have all R14 packages installed and not a mix of 3.5.13.x and R14? The reason I ask is that the docbooks were modified heavily for R14 and I know tde-authors was added sometime after 3.5.13.x. > (2) So now I'm seriously wondering whether I have the time to start testing > TDE package rebuilds. Sorry, I don't really understand--is this good or bad? I don't know whether you are saying you might unexpectedly have extra time to spend on TDE or if it is taking more time already than expected. Thanks! (In reply to mgb-trinity from comment #7) > tqt3-apps-dev is a devel package, derived from qt3-apps-dev. You will note > the package names both end in -dev and the package descriptions both state: > > | This package is intended for developers who want to develop applications > | using the additional static libraries that ship with the applications > | included with ... > > tqt3-apps-dev is definitely not intended to contain shared libraries. Hmm, OK. I'm not sure why Slavek modified that package, but I am still concerned about modifying it to remove shared libraries this close to release. Before I could even consider backing out that change I would need a confirmed list of all packages that were linked against the shared libraries in tqt3-apps-dev so that I could purge and rebuild them. Can you compile such a list? Thanks! (In reply to mgb-trinity from comment #7) > I do not yet know whether KDE3 kdevelop was designed to use static libraries > or whether it was built using shared libraries from a different package. In > part this is because I'm running into a lot of tqt FTBFS due to missing > builddeps and in part because I suspect this software came from Ubuntu > versions and I have a better handle on Debian versions. I am still trying > but I cannot promise results. Forgot to address this. TDE does occasionally show its heritage as an Ubuntu KDE 3.5.10 extension project, and the Debian builds were always a bit of an afterthought, however I try to remove any incorrect Ubuntu-specific changes as I become aware of them. It sounds like you found a fairly major packaging problem, but I don't think it is the result of our past Ubuntu focus. (In reply to Timothy Pearson from comment #9) > Before I could even consider backing out that change I would need > a confirmed list of all packages that were linked against the shared > libraries in tqt3-apps-dev so that I could purge and rebuild them. Can you > compile such a list? A few packages apparently used the shared libraries. Here is a comparison of 3.5.13.2 versus R14 RC1 below. On a 3.5.13.2 system: # apt-cache show qt3-apps-dev | grep '^Version' Version: 3:3.3.8-e-0debian7.0.0+0 # apt-cache rdepends qt3-apps-dev qt3-apps-dev Reverse Depends: libtqtinterface-dev qt3-examples On a R14 RC1 system: # apt-cache show tqt3-apps-dev | grep '^Version' Version: 4:14.0.0-r221-0debian7.0.0+pr46 # apt-cache rdepends tqt3-apps-dev tqt3-apps-dev Reverse Depends: tdevelop-trinity tqt3-linguist tqt3-apps-dev tqt3-apps-dev tqt3-designer tqt3-examples libtqtinterface-dev Slavek, can you comment on the changes introduced in this commit? https://git.trinitydesktop.org/cgit/tde-packaging/commit/?id=4d71fde21440d50d6a4b372921934857fa6da7aa I am looking at backing that patch out but I would like your input in case I have missed important rationale behind it. Thanks! (In reply to mgb-trinity from comment #11) > A few packages apparently used the shared libraries. Here is a comparison > of 3.5.13.2 versus R14 RC1 below. Thanks for the info; looks like tdevelop and (t)qt3 are the only affected modules. Theoretically this means I have the option of backing the patch out for RC2. (In reply to Timothy Pearson from comment #8) > ... apt-get build-dep <package name>. This, combined with > dpkg-buildpackage -rfakeroot, has never lead to a FTBFS result like the one > you posted above. I had been using "mk-build-deps -i -r" and I also tried another recipe at one point but I don't recall which. Just tried "apt-get build-dep" which ultimately resulted in same or similar results. I'll let you know if I figure it out. (In reply to mgb-trinity from comment #13) > (In reply to Timothy Pearson from comment #8) > > ... apt-get build-dep <package name>. This, combined with > > dpkg-buildpackage -rfakeroot, has never lead to a FTBFS result like the one > > you posted above. > > I had been using "mk-build-deps -i -r" and I also tried another recipe at > one point but I don't recall which. Just tried "apt-get build-dep" which > ultimately resulted in same or similar results. I'll let you know if I > figure it out. Yeah I'd be curious to know what happened; builds are chugging away on the build farm with no issues that I'm aware of so something must be wrong on your computer. Are you on Wheezy, Jessie, or something else? (In reply to Timothy Pearson from comment #12) > Slavek, can you comment on the changes introduced in this commit? > https://git.trinitydesktop.org/cgit/tde-packaging/commit/ > ?id=4d71fde21440d50d6a4b372921934857fa6da7aa > > I am looking at backing that patch out but I would like your input in case I > have missed important rationale behind it. > > Thanks! That patch for tde-packaging is necessary in relation to the patch https://git.trinitydesktop.org/cgit/tqt3/commit/?id=2ee14b64 > > (In reply to mgb-trinity from comment #11) > > A few packages apparently used the shared libraries. Here is a comparison > > of 3.5.13.2 versus R14 RC1 below. > > Thanks for the info; looks like tdevelop and (t)qt3 are the only affected > modules. Theoretically this means I have the option of backing the patch > out for RC2. This is probably just a result of the fact that some libraries were previously linking statically, while now they are dynamically. (In reply to Slávek Banko from comment #15) > (In reply to Timothy Pearson from comment #12) > > Slavek, can you comment on the changes introduced in this commit? > > https://git.trinitydesktop.org/cgit/tde-packaging/commit/ > > ?id=4d71fde21440d50d6a4b372921934857fa6da7aa > > > > I am looking at backing that patch out but I would like your input in case I > > have missed important rationale behind it. > > > > Thanks! > > That patch for tde-packaging is necessary in relation to the patch > https://git.trinitydesktop.org/cgit/tqt3/commit/?id=2ee14b64 > > This is probably just a result of the fact that some libraries were > previously linking statically, while now they are dynamically. I still would prefer to keep the dynamic linking. Obviously I would need to update the description text for tqt3-apps-dev to reflect the change to dynamic libraries, but is there any way that we can prevent tdevelop from pulling in a boatload of dev packages that may not be needed for non-C/C++ development? Probing around with ldd it seems that /opt/trinity/lib/trinity/libkdevdesignerpart.so is the only file in the tdevelop package that depends on one of the tqt3-apps-dev shared libraries. I think it would be far more reasonable to move that module to its own package, which can then pull in the dependencies if the user wants to have designer functionality. (In reply to Timothy Pearson from comment #14) > Yeah I'd be curious to know what happened It looks like the FTBFS is caused by TDE picking up a different meinproc from the kde_default_bindirs. In some places TDE does test -n "$TDEDIR" && kde_default_bindirs="$TDEDIR/bin $kde_default_bindirs" but in other places it does kde_default_bindirs="/usr/bin /usr/local/bin /opt/local/bin /usr/X11R6/bin /opt/kde/bin /opt/trinity/bin /opt/trinity/bin /usr/kde/bin /usr/local/kde/bin" I'll look into this some more and if necessary file a separate non-urgent bug report. I have split out kdevdesigner in two commits ending with GIT hash 5839b0d. tdevelop-trinity now suggests kdevdesigner-trinity but does not require it; hopefully this will make the shared library dependencies a bit more palatable. As far as I can tell the package split worked; only kdevdesigner-trinity pulls in tqt3-apps-dev and friends. Is this an acceptable solution to you? Thanks! This looks fixed on my end; marking as such. If the issue persists please reopen this report. Thanks! Fix verified in R14 RC2. |