RFC: what compatibility guarantees do we give for modules != kdelibs ?

[Andreas Pakulat]

On 19.10.09 19:35:58, Alexander Neundorf wrote:
> On Monday 19 October 2009, Andreas Pakulat wrote:
> > On 19.10.09 19:22:32, Alexander Neundorf wrote:
> > > Hi,
> > >
> > > there are more modules than kdelibs which install libraries and headers
> > > (and cmake files) which can be used by other packages.
> > > For kdelibs we guarantee binary compatiblity.
> > > Does this apply to all public libraries and headers inside trunk/KDE/ ?
> >
> > No. Every module gets to pick the policy they want to follow.
> 
> What do we have e.g. for kdebase ?

No idea, I suggest you ask the module coordinator (if there exist one).

> I think kdegames does not care about compatiblity.

Right.

> I guess kdepimlibs is more or less like kdelibs ?

I think so yes.

> > > Motivation: also modules other than kdelibs install cmake-files,
> > > sometimes of medium quality. Keeping an eye on the ones in
> > > kdelibs/cmake/modules/ is enough work, and just because a cmake module is
> > > used inside a KDE svn module, it does not necessarily have to be
> > > installed. But once installed, it can break builds in future versions.
> > > Instead I'm thinking about only installing such modules from kdelibs/,
> > > maybe kdepimlibs/, and change the other modules which install such files
> > > to not install them any longer.
> >
> > And instead you copy those modules across all places that want to find
> > the respective headers/libraries? I don't see how thats going to help
> > with maintaining them.
> 
> Packages don't get broken behind their back.

Right, but if FindFoo.cmake is used by 3 different modules and 6
outside-of-kde apps and it adds a new library or header or changes a
name in one of them you have to fix at least 3 places (or whoever does
that change) where now there's only one place to fix.

Andreas

-- 
Next Friday will not be your lucky day.  As a matter of fact, you don't
have a lucky day this year.