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:
1. 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 a
virtual 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.
--
Slávek