git migration, next steps
kevin.kofler at chello.at
Fri Jun 3 18:18:33 CEST 2011
On Friday 03 June 2011, Jeremy Whiting wrote:
> I also don't see how smaller tarballs == more burden, but I've never been a
It's actually quite simple:
=> 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.
More information about the release-team