RFC v2: adding a temporary, non-BC gauranteed, 'private' library
Friedrich W. H. Kossebau
kossebau at kde.org
Fri Apr 24 20:53:00 BST 2009
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
> 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
> > > 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. :)
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta
More information about the kde-core-devel