[Pkg-systemd-maintainers] Switching the git repository to git-buildpackage

[Michael Stapelberg]

Hi Michael,

Michael Biebl <biebl at debian.org> writes:
> I think I'd put the debian specific changes into patches in
> debian/patches/ with each patch representing such a logical unit.
>
> Upstream fixes I'd like to continue to cherry-pick, but directly to the
> debian branch (no more upstream-fixes branch).
> This would mean, those patches are simply integrated once we merge a new
> upstream release → less work for us.
> That the cherry-picks would end up as giant diff I wouldn't mind, tbh.
>
> What's more important imho is, that the debian specific changes are
> split into a proper patch series.
>
> Michael, to get things moving (and probably the most work) is to create
> such a patch series. Could you start creating a branch, say
> debian-patches, where each change/patch is represented by a single
> commit?
I just created this temporary repository:

http://anonscm.debian.org/gitweb/?p=pkg-systemd/TEMPORARY-systemd.git;a=summary

You can gbp-clone it and use git-buildpackage without any special
configuration to get a working version of the systemd package.

All our modifications are stored in single patches in
debian/patches. I have not yet tagged/documented them all properly, so
they are mostly git log -p contents, but that’s good enough for a
preview.

> As for git-buildpackage: it typically imports full upstream tarballs
> whereas in gitpkg we simply merge the tag from the upstream master
> branch. The benefit of gitpkg is of course that we have the full git
> history.
I still don’t see why this is a benefit. If people want to have the full
upstream git history, adding an upstream remote is trivial. We don’t
need to use that for building our package, though, and I’d argue that
we should use the release tarballs, since upstream specifically prepares
them for use in distributions.

So, what are the next steps? Can we switch over our main repository in
the same way as I did for the temporary repository? (With better commit
messages of course.)

-- 
Best regards,
Michael