git migration, next steps

[Ian Monroe]

On Sat, Jun 4, 2011 at 13:18, Michael Pyne <mpyne at kde.org> wrote:
> 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.

None of the problems you describe are exacerbated by split modules.
We'll have dependencies either way and most KDE modules will have
really simple dependency trees with few intermodule deps.

Ian