On Sunday 20 of December 2015 18:29:36 Michael Howard wrote:
On 20/12/2015 17:11, Slávek Banko wrote:
On Sunday 20 of December 2015 17:28:48 Michael Howard wrote:
- On debian jessie, after building, 'aptitude install tde-trinity'
complains with;
The following packages have unmet dependencies: kitchensync-trinity : Depends: libopensync0 (>= 0.22) which is avirtual package. The following actions will resolve these dependencies:
Keep the following packages at their current version: 1) kitchensync-trinity [Not Installed] 2) tde-trinity [Not Installed] 3) tdepim-trinity [Not Installed]but, libopensync0 isn't available in jessie. Obviously, the packages build because Slavek's repo was in the sources.list. So, what gives? It shouldn't need Slavek's repo in the sources.list to install TDE should it?
libopensync0 is available in extra build dependencies repository - see https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/ubuntu/dep s-r14
These dependencies are available in the official repositories - see http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/ub untu http://mirror.ppa.trinitydesktop.org/trinity/trinity-nightly-build-depend encies/ubuntu
As apt source can be used also preliminary stable builds repository: deb http://mirror.xcer.cz/trinity-sb wheezy deps-r14
Thanks for the reply.
Yes, I know the build dependencies are available, that's how I built the packages :)
What I was wondering is why, having built all the packages (in a chroot) that I could not _install_ 'tde-trinity ' unless I had a build dependency repo in my sources.list. That should not be necessary, surely?
Build-deps in fact are necessary not only at "build time", but they are essential also for user installation - at "run time". For example, akode and libr are for R14.0.x series in build-deps, but are necessary for run time. For R14.1.x are akode and libr already integrated into GIT...
Some packages are in build-deps, because it is an older version of libraries == no longer a part of the distributions and it would be better to update the code so that the libraries will be no longer needed. However, it may require more effort than we have in human resources. For example, library lcms1 - some parts of code has been updated for lcms2, but large applications as digikam and koffice still waiting. And therefore lcms1 is necessary. For such a library seems to be better to update the Trinity code than integrating these libraries into Trinity GIT.