Keeping binary compatibility

[Aaron J. Seigo]

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 
doing so.

> 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...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101004/3e76b9a9/attachment.sig>