Bug#579811: Does linking to libkcal4 really must pull kdepim-runtime ?
Hi, Thanks for the quick reply. On Sat, 2010-05-01 at 03:03 +0300, Modestas Vainius wrote: Hello, On šeštadienis 01 Gegužė 2010 02:16:59 Regis Boudin wrote: I'm the maintainer of Tellico, and I tried to build it against the coming KDE4.4.2 from experimental. I noticed the split of the package into libraries, which is great. However, I also noticed that they pretty much all make the application linking to them depend on kdepim-runtime. This pretty much seems to defeat the purpose of splitting the package, since tellico ends up depending on kdepim-runtime, which in turn pulls akonadi-server (and mysql-server-core as well). This was not a purpose of splitting but rather a side effect. Our *-runtime stuff is still monolithic and it is complicated to split them due to lack of support for such configuration upstream and unpredictable effects on the end applications. Ok, I don't get everything, but the whole thing seems tricky... Tellico is linked to libkcal and libkabc for really non-core features, therefore it would be really nice if you could remove the dependency on kdepim- runtime in the shlibs files, so the users don't end up pulling all the kdepim infrastructure for an optional feature. kdepim is heading towards akonadi being mandatory. You need akonadi to access calendar (kcal) and addressbook (kabc) as of KDE SC 4.4. So that kdepim- runtime injection is rather logical. What is more, could you be more specific which non-core features you have in mind here? It is possible to nitpick kdepim-runtime injection on the symbol level but we need to get those things right from the first try. Tellico is a collection manager. It is linked to libkcal/libkabc because it is possible to mark an item as lent to someone, who can be picked from the KDE address book, and to add to the calendar the date at which they should be returned. So definitely not a core feature, and tellico has been working with KDE 4 and without akonadi for some time now. Thanks Regis -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272709284.2501.16.ca...@x200s
Bug#579811: Does linking to libkcal4 really must pull kdepim-runtime ?
Hello, On šeštadienis 01 Gegužė 2010 13:21:24 Regis Boudin wrote: Tellico is a collection manager. It is linked to libkcal/libkabc because it is possible to mark an item as lent to someone, who can be picked from the KDE address book, and to add to the calendar the date at which they should be returned. So it does access KDE address book and calendar. And now comes the news: you like or not, as of KDE SC 4.4, akonadi MUST be installed and running in order for the user to be able to access KDE address book or calendar. So definitely not a core feature, and tellico has been working with KDE 4 and without akonadi for some time now. As I said before, KDE 4 is changing and akonadi gets more and more integrated with each new major release. KDE SC 4.4 is the point, when you like it or not, akonadi is mandatory to access KDE address book and calendar at runtime from any application. So kdepim-runtime is a valid runtime dependency. So your problem is really about Tellico packaging. I can only suggest two ways to solve it: 1) Split off KDE integration into separate binary package (recommended); 2) Pass -xkdepim-runtime to dpkg-shlibdeps and put kdepim-runtime to Recommends/Suggests manually. And finally, please reassign this bug to yourself :) I don't see how we can help you here. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#579811: Does linking to libkcal4 really must pull kdepim-runtime ?
Hi, On Sat, 2010-05-01 at 13:54 +0300, Modestas Vainius wrote: Hello, On šeštadienis 01 Gegužė 2010 13:21:24 Regis Boudin wrote: Tellico is a collection manager. It is linked to libkcal/libkabc because it is possible to mark an item as lent to someone, who can be picked from the KDE address book, and to add to the calendar the date at which they should be returned. So it does access KDE address book and calendar. Yeah, it seems upstream didn't decide to link against kdepim libraries for no reason. And now comes the news: you like or not, as of KDE SC 4.4, akonadi MUST be installed and running in order for the user to be able to access KDE address book or calendar. It can. I have some news for you, too. I've never used that feature, most tellico users haven't either. It is really a minor feature that can be disabled at build-time. So definitely not a core feature, and tellico has been working with KDE 4 and without akonadi for some time now. As I said before, KDE 4 is changing and akonadi gets more and more integrated with each new major release. KDE SC 4.4 is the point, when you like it or not, akonadi is mandatory to access KDE address book and calendar at runtime from any application. So kdepim-runtime is a valid runtime dependency. I understand that Akonadi is mandatory to access the address book and calendar, but having such access is really not mandatory for tellico to be perfectly usable. It is a collection manager, not a loan manager. So your problem is really about Tellico packaging. I can only suggest two ways to solve it: 1) Split off KDE integration into separate binary package (recommended); splitting off KDE integration from a KDE application might be tricky... Just splitting off kdepim integration means intrusive changes to the code, which upstream might not want to merge, that I'm not willing to maintain myself, and that I'm not sure I could stabilise in time for the release. 2) Pass -xkdepim-runtime to dpkg-shlibdeps and put kdepim-runtime to Recommends/Suggests manually. or 3) Disable completely kdepim integration completely... I will go for the dpkg-shlibdeps override. People who will want to use that feature will most probably have the actually required applications installed (kaddressbook, korganiser), which I might add as suggests. And finally, please reassign this bug to yourself :) I don't see how we can help you here. Yeah, not much help, here... If you think the bug is not relevant, please close it. Regis -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272715313.2501.46.ca...@x200s
Bug#579811: Does linking to libkcal4 really must pull kdepim-runtime ?
Package: libkcal4 Version: 4:4.4.2-1 Severity: normal Tags: experimental Hi, I'm the maintainer of Tellico, and I tried to build it against the coming KDE4.4.2 from experimental. I noticed the split of the package into libraries, which is great. However, I also noticed that they pretty much all make the application linking to them depend on kdepim-runtime. This pretty much seems to defeat the purpose of splitting the package, since tellico ends up depending on kdepim-runtime, which in turn pulls akonadi-server (and mysql-server-core as well). Tellico is linked to libkcal and libkabc for really non-core features, therefore it would be really nice if you could remove the dependency on kdepim- runtime in the shlibs files, so the users don't end up pulling all the kdepim infrastructure for an optional feature. This abviously applies to the libraries tellico depends on, but probably to all the other lib packages built from kdepimlibs. Thanks, Regis -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libkcal4 depends on: ii libc6 2.10.2-7 Embedded GNU C Library: Shared lib ii libical0 0.44-3 iCalendar library implementation i ii libkabc4 4:4.4.2-1 library for handling address book ii libkdecore5 4:4.4.2-1 the KDE Platform Core Library ii libkdeui5 4:4.4.2-1 the KDE Platform User Interface Li ii libkio5 4:4.4.2-1 the Network-enabled File Managemen ii libkpimutils4 4:4.4.2-1 library for dealing with email add ii libkresources44:4.4.2-1 the KDE Resource framework library ii libqt4-xml4:4.6.2-4 Qt 4 XML module ii libqtcore44:4.6.2-4 Qt 4 core module ii libqtgui4 4:4.6.2-4 Qt 4 GUI module ii libstdc++64.5.0-2The GNU Standard C++ Library v3 libkcal4 recommends no packages. libkcal4 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100430231659.9757.37095.report...@x200s
Bug#579811: Does linking to libkcal4 really must pull kdepim-runtime ?
Hello, On šeštadienis 01 Gegužė 2010 02:16:59 Regis Boudin wrote: I'm the maintainer of Tellico, and I tried to build it against the coming KDE4.4.2 from experimental. I noticed the split of the package into libraries, which is great. However, I also noticed that they pretty much all make the application linking to them depend on kdepim-runtime. This pretty much seems to defeat the purpose of splitting the package, since tellico ends up depending on kdepim-runtime, which in turn pulls akonadi-server (and mysql-server-core as well). This was not a purpose of splitting but rather a side effect. Our *-runtime stuff is still monolithic and it is complicated to split them due to lack of support for such configuration upstream and unpredictable effects on the end applications. Tellico is linked to libkcal and libkabc for really non-core features, therefore it would be really nice if you could remove the dependency on kdepim- runtime in the shlibs files, so the users don't end up pulling all the kdepim infrastructure for an optional feature. kdepim is heading towards akonadi being mandatory. You need akonadi to access calendar (kcal) and addressbook (kabc) as of KDE SC 4.4. So that kdepim- runtime injection is rather logical. What is more, could you be more specific which non-core features you have in mind here? It is possible to nitpick kdepim-runtime injection on the symbol level but we need to get those things right from the first try. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
