[Kde-scm-interest] [Proposal] Package splitting with thin meta-repos

[Alexander Neundorf]

On Saturday 27 March 2010, Maciej Mrozowski wrote:
> On Friday 26 of March 2010 19:24:18 Alexander Neundorf wrote:
> > On Friday 19 March 2010, Alexander Neundorf wrote:
> > > On Thursday 11 February 2010, Alexander Neundorf wrote:
> > > > On Monday 08 February 2010, Maciej Mrozowski wrote:
> > > > > On Monday 08 of February 2010 12:42:02 Mike Arthur wrote:
> > > > > > On 6 Feb 2010, at 14:41, Maciej Mrozowski wrote:
> > > > > > > How about moving all shared .cmake files to either separate
> > > > > > > package (or maybe with modules fetched from Internet, sth like
> > > > > > > knewstuff or PEAR or just SVN) - as current kdelibs cmake
> > > > > > > policies are too strict, besides rebuilding kdelibs just to get
> > > > > > > newer cmake files seems silly. That would benefit both cases
> > > > > > > imho.
>
> Refining this initial idea:
> What about setting up sourceforce (or kdesupport/gitorious) project: cmake-
> modules, being modules incubator for cmake
> - with own release schedules
> - depending on >= particular cmake version
> - installing .cmake modules in unknown <some_modules_path>
> - providing own FindCMakeModules.cmake file that sets
> CMAKE_MODULE_PATH=<some_modules_path> and provides CMAKEMODULES_VERSION (so
> that find_package(CMakeModules <version>) can be used

Such a package will/should have the same compatibility requirements as the 
modules in kdelibs.
This is actually my main point. Someone writes a module, it kind of works, and 
he tries to get it into <some always installed package>, so others can use it 
too. Good so far, but this also means this module has to keep compatibility 
starting with the first release, for the years to come.
Such a separate package would be like a libkrandomstuff.so, which is required 
by kdelibs but doesn't provide any compatibility guarantees.

I think I'm not in favour of this idea.

> Main (only?) benefit is being decoupled from kdelibs (so more relaxed
> schedules), also - ideally it would allow to get rid of all
> application-local modules. It brings additional maintenance cost (releases
> etc) but would be neutral (not tied to KDE) and thus maybe KitWare itself
> could be more interested in such idea.
> CMake is getting more and more popular, but it's sad seeing so many poorly
> written CMake buildsystems worldwide with locally hacked, sub-optimal
> .cmake modules only because there's no community-driven central place for
> their development and because those provided by cmake itself are not ideal
> either.
>
> > > > > > How are the current KDELibs CMake policies "too strict"? What
> > > > > > problems are these causing?
> > > > >
> > > > > http://techbase.kde.org/Policies/CMake_and_Source_Compatibility
> > > > > (general) http://techbase.kde.org/Policies/CMake_Commit_Policy
> > > > > (kdelibs/cmake)
> > > > >
> > > > > KDElibs CMake policies cause no problems - they solve them. It's
> > > > > just this strictness currently may seem to discourage developers
> > > > > from getting their .cmake files in shape and pushing them to
> > > > > kdelibs instead of bundling within modules (like kdenetwork etc).
> > > >
> > > > If we would have another package just consisting of cmake files, I
> > > > think the same rules would have to apply to it, and I think this may
> > > > have the same effect on the developers.
> > > > Installing cmake files comes with a cost, so not sharing them if they
> > > > are used only in some very rare cases also has advantages.
> > >
> > > How about this: instead of installing a bunch of FindFoo.cmake files,
> > > we could just collect them e.g. in kdesdk/cmake/modules/ or something
> > > like that. If somebody needs a module, he gets a copy from there and
> > > includes this in his application.
> > > This way we wouldn't have to care about compatibility, and still we
> > > would have a place where people could manually get cmake find-module
> > > files.
>
> Hmm, my first thought was that it's going to be worse than current
> situation as one cannot automatically propagate fixes to those .cmake files
> in such case.
> But in the same way, one cannot automatically break those modules so there
> is some merit in this.

That's my main point. 

> It indeed is better in terms of compatibility, on the other hand it leads
> to possibly unlimited number of possibly incompatible forks.

Well, "forks". Let's say modified copies. Those modified copies don't have to 
be installed or published, so I wouldn't call it a fork (sounds like ongoing 
competetive development). And they can always update manually (<- important) 
again from that one central (but uninstalled) location.

> Not bad idea imho.

Others ?

Alex