RFC: Release Management Going Forward
neundorf at kde.org
Fri Jun 24 11:39:25 CEST 2011
On Thursday 23 June 2011, Nicolas Alvarez wrote:
> Rex Dieter wrote:
> > On 06/21/2011 06:41 AM, Will Stephenson wrote:
> >>>> So you want the fine grained tarballs, if I understand correctly ?
> >>> Just looking at how the openSUSE buildservice is set up, they seem to
> >>> use fine-grained tarballs as well, although I don't know how closely
> >>> those match to the breakdown you are using.
> >> We're using them, and the consensus among the team so far is that they
> >> allow faster builds (broader dependency tree instead of deeper) and
> >> isolate failures better. These are the kde.org tarballs; is anyone using
> >> their own??
> > Fwiw, in fedora, we hacked the 4.6.80 kde.org tarballs and build-process
> > to be as-close-to-monolithic as possible.
> I had to do many changes to the buildsystem of every kdeedu app in 4.6 to
> let them build both monolithic and split. If you need to continue with a
> monolithic build, (and preferably if fedora is not the *only* distro that
> needs it), I'm willing to forward-port the changes to the master branch.
> However, IMHO, KDE shouldn't officially release both sets of tarballs. That
> would be a mess.
Please have a look at the Superbuild CMakeLists.txt I did for kdegraphics.
It can build all-in-one, but then internally each repository is included as a
cmake "ExternalProject", i.e. it still builds as if it was independent (but
controlled by the super-CMakeLists.txt):
And you can not only do that, you could also write such a super-CMakeLists.txt
for the whole KDE SC, enable only e.g. potato guy, and it will iteratively
tell you which additional subprojects you need to enable to have all
Then you can build exactly that.
Or you could create a source package consisting of exactly those subprojects
needed for potato guy.
I haven't done this for whole KDE SC yet, but I tested it on kdegraphics and
kdesupport so far and it works.
I'm basically waiting for more feedback especially from packagers.
More information about the release-team