Keeping binary compatibility
Aaron J. Seigo
aseigo at kde.org
Mon Oct 4 18:50:02 BST 2010
On Sunday, October 3, 2010, George Kiagiadakis wrote:
> On Sun, Oct 3, 2010 at 12:14 AM, Aaron J. Seigo <aseigo at kde.org> 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.
ah, to add its own additional weather source plugins which upstream can not
distribute due to legal issues with use policies (or lack thereof) of the
websites they use.
and yes, there is no explicit binary compat guarantee on that library. it does
use dtprs and what not, but it isn't watched explicitly. it probably should be
moved to kdebase-workspace/libs/ and in line with this thread have a binary
compat commitment documented.
> > 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".
agree or not, it makes some things far more manageable and achievable. i care
less about the theoretical cleanliness of the modules with regards to each
other than i do about that kind of pragmatic benefit.
> 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.
i can see how this can be an issue in some cases and we need to be careful not
to weave all the modules too tightly together just because we can. however,
for modules like kdeplasma-addons, kdebase-workspace/plasma and kdelibs, it
totally makes sense to do so. does that make life less happy for packagers? i
don't know, to be honest, but it makes the developers and the users more happy
because we can offer more features and greater consistency in less time by
> Different modules are different packages for us, there
> isn't much difference between that and an extragear package.
there is a big difference for the upstream developers. it confers a number of
very useful assumptions that we take advantage of all the time. for example,
new api in libplasma is immediately usable by items in kdeplasma-addons. this
means they don't need to remain backwards compatible. this is a very nice
benefit over doing the same thing in extragear.
> 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.
i agree that documenting these things is very important, yes.
> This will at least reduce the pain when
> users need to mix different versions that *can* be used together. Of
there's also the case of "these modules are not independent from each other".
> > perhaps we need a "internal to KDE SC" header install location?
> Application authors could still use them for apps outside the SC. How
sure, as Parker notes there's no way around a clever developer. howevver, this
install location would not need to be shipped as part of normal dev packages
(only needed for building other SC modules), it would be documentary to the
app developer that "this is not for you" and it would remove them from the
default include paths in our cmake variables which would force app developers
to purposefully work around it (putting the responsibility on them, imho)
> are we going to force them not to do that? And what if they really
> need the functionality provided by this library?
then they can come talk to upstream about getting it made into a public
library. which is what we already do.
> That sounds like an
> evil plan to pull even more applications into the SC while they could
> perfectly fit in extragear or somewhere else.
it isn't. it's a way of confering useful benefits to the components that are
part of the SC releases. but it isn't a reason to make something part of the
SC. if the only reason is "to share that currently private library" then the
policy of that library needs to be examined.
for things that are legitimately part of the SC, however, i see no reason to
skip over opportunity for improvement in development such as reasonable
sharing of libraries between modules.
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel