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

Maciej Mrozowski reavertm at gmail.com
Sun Jan 31 14:39:31 CET 2010


On Sunday 31 of January 2010 08:59:17 Thiago Macieira wrote:
> Em Domingo 31. Janeiro 2010, às 02.06.58, Oswald Buddenhagen escreveu:
> > afaict, it has worked so far (except for the mess in kdebase).
> > obeying of the rules can be verified with a stand-alone automatic
> > dependency walker, or by simply having the dash bot check out and build
> > incrementally according to the dependencies.
> 
> It has worked so far in kdebase because it's everything in the same module.
> CMake takes care of walking the dependency tree and resolving it. Everyone
> downloads the entire module, all the time, so they have everything.
> 
> I don't like the option of going from a dozen big modules plus some extra,
> interesting apps, to 140 packages. I really don't. What are we going to
> tell packagers?
> 
> "You know those simple rules we had you follow so far? Forget them. Now
> it's as complex as GNOME. Actually, only a bot now knows what depends on
> what. We want you to use this script to build KDE in your distribution
> (yeah, forget your current dependency mechanisms too)."

What packagers are you referring to Thiago? Dirk and Co. or distro packagers?

Source distro packagers (like here in Gentoo) surely prefer splitting - as 
they (we) do it anyway now, by the means of custom/hacked solutions like 
recursively commenting out certain add_subdirectory sections using clever sed 
scripts often accompanied with total override of find_package(..REQUIRED) 
lines like with the example of kdepim (this one is not going to be split 
easily, I'm not sure whether it's even worth it).
And dependencies are discovered and adjusted by packagers anyway 
(CMakeLists.txt files have just informative role) - I don't see it in any way 
related  to current dependency mechanisms unless I'm missing something.
That being said as distribution packager (TM), I'm all for introducing 
official/blessed way of splitting (buildsystem-wise) of KDE SC.

-- 
regards
MM


More information about the Kde-scm-interest mailing list