[Kde-scm-interest] [Proposal] Package splitting with thin meta-repos
Thiago Macieira
thiago at kde.org
Sun Jan 31 15:19:17 CET 2010
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
More information about the Kde-scm-interest
mailing list