liboxygenhelper?

[Andreas Pakulat]

On 10.08.09 08:13:43, Thiago Macieira wrote:
> Andreas Pakulat wrote:
> >On 09.08.09 21:04:50, Sune Vuorela wrote:
> >> On 2009-08-09, Tom Albers <toma at kde.org> wrote:
> >> > --nextPart40319998.LmhcOLVCHR
> >> > Content-Type: text/plain
> >> > Content-Transfer-Encoding: 7Bit
> >> >
> >> > Op Sunday 09 August 2009 07:08 schreef u:
> >> >> On 2009-08-08, David Faure <faure at kde.org> wrote:
> >> >> > Any comments or objections?
> >> >>
> >> >> I object to anything that involves abi-unstable libraies with
> >> >> public headers in kdelibs.
> >> >>
> >> >> /Sune
> >> >
> >> > Why? It's similar to what akonadi does:
> >> > install a libakonadiprivate.so and install headers like
> >> > itempayloadinternals_p.h. The naming should provide enough hints to
> >> > developers to not use it blindly.
> >>
> >> akonadi is not part of kdelibs
> >> so far, I've been told that akonadiprivate is only named private "to
> >> scare off people who don't know what they are doing", not because it
> >> isn't keeping a stable abi
> >> and I do expect akonadiprivate to use a proper abi stability policy
> >> (change major version of soname on BIC changes between releases)
> >
> >So I guess your problem with library that doesn't keep BC in kdelibs is
> >that you might have to change kdelibs name on each release? If thats the
> >case, this is basically a "packagers-only" issue and could easily be
> >solved by simply splitting out this single lib from kdelibs and
> >providing a separate binary package for it. I'm assuming that
> >liboxygenhelper plays by the rules and changes its SONAME when breaking
> >BC.
> 
> The problem is about providing a separate binary package for it. That's 
> pretty clear.

I assume there's a "not" missing in that sentence?
 
> The problem is about providing a separate *source* package for it. If KDE 
> doesn't do that, it becomes very difficult for packagers.

Why? They already split up several of our source packages when building
binary packages. I don't see why that would be harder for kdelibs than
for any other of our source packages.

> The policy we came up for experimental libs solves that, by forcing 
> separate source releases. If oxygenhelper wants, it can do exactly that.

As was said elsewhere, that was intended for libs that are going for a
stable API. In this case thats not going to happen AFAIU.

Andreas

-- 
You will get what you deserve.