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

[Marco Martin]

On Friday 24 April 2009, Friedrich W. H. Kossebau wrote:
> Le Freitag, 24. April 2009, à 12:51, Kevin Krammer a écrit:
> > On Friday, 2009-04-24, Friedrich W. H. Kossebau wrote:
> > > Vrendedi, le 24 avril 2009, à 12:10, Thiago Macieira a écrit:
> > > > We want to have knotificationitem-0.1.tar.gz. The place for
> > > > individual packages is extragear.
> > >
> > > Also for those which are a hard dependency for e.g. kdebase?
> >
> > 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.
> 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.
so we say in the module that will enclose knotificationitem will be only stuff 
that can stay here in the dependency chain, if for instance a lib from pimlibs 
wants to do something similar it will have to go in a new module after pimlibs 
in the deps

or, let's put it directly after kdepimlibs
painful in any way it's looked at but it will bring better libraries in the 
end, i really believe it.

Cheers,
Marco Martin
>
> > > Or kdepimlibs
> > > (who perhaps might be happy to have some more time to make the
> > > akonadi-based APIs stable)?
> >
> > We do that in module private libs in kdepim.
>
> Private as in? Are the libs used outside of kdepimlibs?
> Are headers installed whose API changes incompatible for 4.x+1?
> Would kdepim 4.3 compile against kdepimlibs 4.4, or rather, would kdepim
> 4.3 compiled against kdepimlibs 4.3 run with kdepimlibs 4.4?
> Then I just guessed these published parts of kdepimlibs are still candidate
> for changes, so it might have been a bad example :)
>
> > > For myself I would be happy to publish the okteta{core,gui} libs for
> > > reuse by others. But they are not extra to Okteta, they are
> > > fundamental. And will just change and be released along major KDE
> > > versions. So _extra_gear really does not fit for it IMHO. I would very
> > > much like another solution.
> >
> > 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?
>
> Cheers
> Friedrich