git migration, next steps

[Ian Monroe]

On Fri, Jun 3, 2011 at 11:18, Kevin Kofler <kevin.kofler at chello.at> wrote:
> 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.

Yea honestly since Slackware is the only distro in the world probably
to not split stuff up, I would've thought everyone else would be
thankful for splitting since it shifts responsibility for documenting
intra-modules dependencies upstream to us. All the KDE distro
maintainers are probably just trained to deal with meta-project
tarballs, but that doesn't really mean it makes the most sense.

Also lets try to split up (haha!) the issue between what we want to do
longterm and what we need to do in the short term.

Ian