[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: git migration, next steps
From:       Michael Pyne <mpyne () kde ! org>
Date:       2011-06-07 23:02:34
Message-ID: 4608145.M12eU2a10Y () midna
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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" (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]