git migration, next steps

[Michael Pyne]

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?

Ian,

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

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

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

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.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110604/c90d8010/attachment.sig