RFC v2: adding a temporary, non-BC gauranteed, 'private' library

[Friedrich W. H. Kossebau]

Vrendredi, le 24 avril 2009, à 21:16, Kevin Krammer a écrit:
> On Friday, 2009-04-24, Friedrich W. H. Kossebau wrote:
> > > It is just another external library, i.e. it is either optional for
> > > additional features or required, in which case it needs a CMake check
> > > for the required version.
> >
> > Sure. But see this from a KDE developers point of view: It increases the
> > complexity of the whole build process. Where one was used to think in
> > modules without needing to care much what is contained, one now also has
> > to always think of the individual packages which are linked into the
> > dependency chain and always need to be up-to-date.
>
> As with any other external library I would just install the respective
> development package.
> At least I don't build all the dependencies from source when building KDE
> from trunk.

But knotificationitem isn't an external library. It is a wanna-be part of 
kdelibs, just not API-stable enough to be included officially currently. So 
knotificationitem-trunk depends on kdelibs-trunk. And module-trunk depends on 
knotificationitem-trunk and kdelibs-trunk. A development package might not be 
up-to-date enough (unless you mean tuesday-trunk-packages?).

> > Where it was
> > 	kdesupport->kdelibs->kdepimlibs->kdebase->kdeutils
> > it would become
> > 	kdesupport->kdelibs->knotificationitem->kdepimlibs->kdebase->oktetalibs-
> >> kdeutils
> > and perhaps worse, if more developers take chance of giving their libs
> > some publish feedback before freezing the API.
>
> No, in both cases
> kdelibs->kdepimlibs->module.
>
> You would only need to inject knotificationitem if for whatever reason you
> want to build an not-yet-released version.

? I am talking of trunk. Here all things could change BIC on mondays, and 
dependant modules are allowed to depent on the version of the latest monday. 
So I always need uptodate packages, at least if i don't track all BIC changes 
to know if I really need to update. But I guess we lost each other somewhere 
here.

> > > We do that in module private libs in kdepim.
> >
> > Private as in? Are the libs used outside of kdepimlibs?
>
> They are in kdepim, so yes outside of kdepimlibs.

Ah, sorry, misread kdepim for kdepimlibs in your first sentence, so the rest 
of my question was bogus.

> > > If they are specific to a certain version of Okteta, just release them
> > > with that version, no?
> >
> > But as far as I was told once they are released and published with
> > kdeutils, I have to ensure ABI-stability until KDE5. Or? Or do you mean
> > release them from extragear?
>
> Well, if you define the stability guarantee for your libs that way, then
> you should probably stick to it.
> I just thought you might not follow the stricter rules for platform
> libraries. Usually application level APIs are far less stable.

As written in another email, I had missed the lift of this stricter rules for 
non-platform libs a few month ago, so my assumptions regarding the oktetalibs 
were not up-to-date. :)

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta