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

[Patrick J. Volkerding]

Sorry, left kde-scm-interest off the reply.

-------- Original Message --------
Subject: Re: [Kde-scm-interest] [Proposal] Package splitting with thin 
meta-repos
Date: Sat, 06 Feb 2010 12:54:41 -0600
From: Patrick J. Volkerding <volkerdi at slackware.com>
To: kde-packager at kde.org

On 02/06/2010 08:41 AM, Maciej Mrozowski wrote:
> f) straightforward distro packaging
>
> - modules - impossible. Nearly all distributions split KDE so it seems that's
> common use case.

Slackware packages KDE with the same package names as the upstream KDE
tarballs.  It works great for us, and really couldn't be simpler to
maintain.

> "You know those simple rules we had you follow so far?
> It is by no means simple rule even for them (binary distros) - as they need to
> discover dependencies anyway.

Not necessarily.  If the distribution enforces dependencies, then
they've created that little puzzle for themselves.  In the case of
Slackware, the users know that if they install all of the KDE packages
the pieces will take care of themselves.

> Solution?
> If packages were split in such fashion that's directly suitable for their
> distribution downstream - like *cough*Gnome*cough* - at least distro packagers
> wouldn't need to worry about discovering dependencies.

That worked so well for GNOME that we quit shipping it.  Everything
began to diverge, and there was no clear way to know exactly which
versions of the components were needed for a given "release".  Worse,
often there were cases where something would require foo version A, and
something else in the same release wanted foo version B.  If you weren't
a GNOME developer, you almost couldn't find out the details needed to
build it, and issues of build order were amplified to a massively
annoying degree.

> But.. it moves a bit of dependency maintenance burden from distro packagers to
> KDE developers.

Why should the maintainers of the source code have to concern themselves
with binary dependencies?  They did not create that problem.

> And one note about Thiago response:
>> 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)."

I have to mostly agree with Thiago.

> In Gentoo we're perfectly capable of build-time splitting and maintaining
> multiple packages. Currently we have ~280 packages  for every KDE SC release.

If that works for you, wonderful.  But I'd be beyond disappointed to see
upstream KDE split up that way.

> My overall suggestion would be:
> If you want to have git migration done, postpone package splitting (for now).

My suggestion would be:

Please don't ruin KDE.  Having a reasonable number of source tarballs is
one of KDE's greatest strengths.  It's nice to see a project of KDE's
complexity that can be compiled by a technically-inclined end user, and
not only by the project's developers (or people who are nearly so).

Regards,

Pat