git migration, next steps
mpyne at kde.org
Sat Jun 4 20:18:16 CEST 2011
On Friday, June 03, 2011 10:56:12 Ian Monroe wrote:
> >> If you want to give people a feeling of unity (pun intended) when
> >> running KDE it should not be given to packagers as a shambles of small
> >> un-coordinated source tarballs.
> > I agree with you there.
> It's still release-team at kde.org not release-team-ark,
> release-team-marble etc etc. Why would split tarballs for 4.7 be an
> uncoordinated shambles?
Having a million difference source tarballs required is a pain even for
kdesrc-build, and that's even with the fact that individuals are graciously
fixing the kdesrc-buildrc-sample as necessary to keep up with changes to Git
Exposing the KDE project infrastructure over kde_projects.xml was/is supposed
to be the fix for the explosion of source modules in kdesrc-build, but what
has /actually/ happened for many modules in the kdesrc-buildrc-sample is that
every single individual subproject for a given "virtual module" like
kdegraphics has to still be spelled out by hand.
And if you want to simply build individual projects, there's no clean way
working straight from source tarballs to know beforehand which KDE deps you
For instance I can no longer build Digikam because it required libkface,
libkmap, and more which are documented in their CMakeLists.txt, but require
Fortran to work for some face recognition algorithm. The point is not to
complain about the fact that Fortran is required, but that I had to dig under
quite a bit of separate subprojects, always trying to install separately,
until I figured out that I would not be able to build Digikam for that reason.
Even other projects that are more straightforward are difficult to deal with
dependencies sanely. There is no information in the kde_projects.xml to relate
what git projects depend on which other ones, so every single individual
package from a packager's point of view represents some non-trivial amount of
work to handle, as it is not as if it's a flat dependency tree where a given
git module depends only on e.g. Qt and kdelibs. Areas where we might have,
back in the day, included dependencies all in the same module and made sure
they built in the proper order in CMakeLists.txt now get punted to the
Now many packagers have taken this task on board /anyways/ and so splitting
things up on our part makes it easier on these packagers. But it's not
uniformly easier across the board for all packagers, and it's not like our
current migrations have been exceptionally-well coordinated on this mailing
list. Just look at the troubles that have occurred doing nothing more than
trying to tag 4.6 follow-on releases.
So you see, it's not as simple as just doing some copy/paste on a bunch of RPM
spec files or whatever. Every individual package that gets created represents
actual work to do.
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110604/c90d8010/attachment.sig
More information about the release-team