git migration, next steps

[Kevin Kofler]

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