Am 07.02.2013 23:32, schrieb Frank Reininghaus: ... Since I am reading this thread by chance, I might as well reply.
One of the reasons of splitting kdelibs into separate repositories is to simplify the usage of single modules. >From the perspective of a full *KDE* desktop, there is no problem in building & using all of kdelibs, since each library will be used several times from several applications. If you do not have a full *KDE* desktop (running a single KDE application on a gnome desktop or maybe the wish to use KDE technology in your Qt application), this will not be the case, and you will generate overhead. Of course the overhead can be cut down by (1) splitting kdelibs either at buildtime (by switching libraries on or off at cmake time) or (2)after building it (currently done by some distros to some extend). For KDE on Windows e.g. (1) will bring the overhead of having a complete kdelibs package for rather tiny libraries and (2) is simply forbidden by missing manpower. Another argument against splitting is that developers will have to update multiple repositories. As mentioned by others this problem can be solved by using git submodules, or even other ways of scripting. >From a packagers point of view, I doubt that the number of repositories/tarballs matters since packaging is scripted. I cannot see any advantage from keeping tierX together in one repository too because the same problems apply. I hope this helps a bit, regards, Patrick _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
