On Tuesday, June 07, 2011 19:55:24 Modestas Vainius wrote: > Hello, > > On penktadienis 03 Birželis 2011 17:27:41 Rex Dieter wrote: > > Split tarballs *after* migrations are final and where it can be > > carefully planned and executed would be more welcome, say for kde-4.8. > > Personally, I'm in favour of split tarballs. But as there seems to be so > much opposition to this approach [1], I could take return to old ways with > everything except kdebindings. Could you please keep that ugly beast split > in 4.7 and on onwards?
I don't think anyone (even Slackware packagers) are opposed to split tarballs being available, or even the default. >From what I can tell the Slackware packagers would have significantly less "packaging" burden if monolithic tarballs are available. For what it's worth as kdesrc-build author trying to maintain a sample configuration, I agree completely, and I make it a business to keep dependency handling as simple as possible! Actually having to key in dependency data as the packagers would have to do is more work and while the consensus from most packagers seems to be that they were doing that work /anyways/ (and therefore split tarballs are fine), that's not the case for all of them. A separate objection had come about from the process of creating split tarballs (e.g. kdeedu migration as annma already mentioned), not the idea of having split tarballs itself. I think most of us would agree that a smooth migration to split tarballs is the much preferred mode of operation if we're going to be migrating at all, so I don't see that as controversial either. So in other words: Split tarballs are still the answer, but taking a little bit of extra work on our end to get a decent monolithic compilation can help some of packagers save a significant amount of maintenance burden, and as we transition over we just need to take advantage of past experience to try and ensure everything moves as smoothly as possible. Regards, - Michael Pyne
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
