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

[Thiago Macieira]

Em Domingo 31. Janeiro 2010, às 14.39.31, Maciej Mrozowski escreveu:
> 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?

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).

Source distros are the minority. Sure, for you, splitting is much better, 
since you need to download the source before compiling.

For traditional binary distros, it doesn't really matter if the source comes 
in separate packages or in one big bundle. They're going to split it anyway.

And they usually split differently, from one distro to the next.

> 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.

Remember you're doing this for about 20 packages (a dozen modules, plus a 
handful of important apps from extragear).

Now repeat that procedure to 140 packages. Or more, since the list will grow.

You said yourself that the CMakeLists checks are just informative. So I want 
to see you do that for the 140 Git repositories. Plus *everyone* else who 
builds from sources not using Gentoo ebuilds. We can provide a script to do 
the dependency tracking and order the build right. Are you going to use it in 
your distro?

I'm not saying that package splitting has no benefits. I can recognise the 
benefits.

What I'm saying is that uncontrolled dependency mapping will lead to chaos. 
That's exactly why Patrick kicked GNOME out of Slackware: figuring out the 
dependencies was too hard. So what I'm saying is that, *IF* we split packages, 
we need to have clear, sensible rules right from the start on what the 
dependencies are.

PS: we have not discussed what happens if our split doesn't match the distros' 
split. Any/all of them.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100131/3b61649b/attachment.sig