On Friday 03 June 2011, Jeremy Whiting wrote: > I also don't see how smaller tarballs == more burden, but I've never been a > packager.
It's actually quite simple: smaller tarballs => more source packages (unless you jam multiple tarballs into the same source package, which is generally frowned upon in the RPM world and might not even be technically possible in some other packaging systems) => more burden: more initial package reviews to go through, more specfiles to update with every release, more builds to issue with every release, more build-time dependencies to keep track of etc. Most of this work is per source package and not per binary package, so even doing split packages from unsplit source tarballs would be significantly less work. But since it is only possible to build multiple binary subpackages from one source package and not the other way round, having split tarballs effectively also forces us to do split binary packages (unless we go with the multi-tarball SRPM hack), removing flexibility from us. Doing split binary packages in turn has other problems, e.g. huge update metadata when we push a new version (e.g. a bugfix point release) as an update. Kevin Kofler _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team