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@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
