On Sun, Oct 3, 2010 at 12:14 AM, Aaron J. Seigo <[email protected]> wrote: > On Saturday, October 2, 2010, George Kiagiadakis wrote: >> % aptitude search >> '?not(?source-package(kdebase-workspace))~Dlibweather-ion4a' p >> plasma-dataengines-yawp - yaWP's data engines (Ions) for >> different weather servicesd > > does yawp actually _link_ to the ions? or does it just load them as DataEngine > plugins at runtime?
It links to libweather_ion.so.4. Such package dependencies in debian packages are determined automatically by checking the headers of the binaries. >> % aptitude search >> '?not(?source-package(kdebase-workspace))~Dlibplasmaclock4b' >> i A plasma-widgets-addons - additional widgets for Plasma >> >> (plasma-widgets-addons is kdeplasma-addons) >> >> % aptitude search >> '?not(?source-package(kdebase-workspace))~Dlibkworkspace4' p kshutdown >> - an advanced shut down utility for KDE >> i ktorrent - BitTorrent client based on the >> KDE platform >> p plasma-widget-fastuserswitch - Fast user switch plasmoid for >> switching between sessions in KDE >> i A plasma-widget-lancelot - lancelot widget for Plasma >> >> % aptitude search '?not(?source-package(kdebase))~Dlibkonq5a' >> i ark - archive utility >> i A kdesdk-dolphin-plugins - dolphin vcs plugins >> c kmess - MSN messenger for KDE >> c konq-plugins - plugins for Konqueror, the KDE >> file/web/document browser > > aside from kmess and ktorrent, these are things that are released together. kmess and ktorrent + kdevelop, plasma-widget-yawp, plasma-widget-fastuserswitch, sentinella, kshutdown, konq-plugins (which is not released with the SC afaik, or at least there is no konq-plugins 4.5) and lots of other apps and plasmoids from kde-apps.org that are not packaged in debian. > that they share such libraries is property of the SC release paradigm. it's > not a bad thing. what is bad is that software outside of the SC does > similarly, in part because we install headers so people can build modules > separately. I am not sure I agree to the "SC release paradigm". It is fine if a private library is shared across the same module, but sharing it across different modules causes problems because it is not always possible to upgrade all the modules at once and causes unecessary pain for the users. Different modules are different packages for us, there isn't much difference between that and an extragear package. However, this might be acceptable if BIC changes are documented for each release, so that we know when different module versions can be mixed and when they cannot. This will at least reduce the pain when users need to mix different versions that *can* be used together. Of course, the best way to achieve this would be to bump (or not bump, if there is no BC break) sonames, which is immediately visible to the packagers. So, I think we are back to the original proposal :) > perhaps we need a "internal to KDE SC" header install location? Application authors could still use them for apps outside the SC. How are we going to force them not to do that? And what if they really need the functionality provided by this library? That sounds like an evil plan to pull even more applications into the SC while they could perfectly fit in extragear or somewhere else. _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
