Re: Standardizing the layout of git packaging repositories
Hi,
On Sat, 16 Aug 2014, Philip Muskovac wrote:
> I'm writing this from a Kubuntu POV which should be close to
> debian-qt-kde as we have a pretty close workflow (one of the reasons why
> we're talking about moving our branches to their repositories) as we
> also only keep the debian/ dir in the VCS.
Thanks for your feedback! A couple of comments though:
> a) Consistent VCS based packaging workflow
> While upstream has switched most of their repositories to git,
> there's a couple (artwork related) repositories that are kept in
> SVN, so if we would use a git-based workflow with source and
> packaging together, we would have to manage different workflows
> for specific packages within the same release which is something I
> would prefer not to do.
In both cases upstream releases tarballs, no? So that could be the layer
that offers the consistency that you're looking for (with the help of gbp
import-orig).
> b) Repository size
It's clear that having the upstream sources takes a lot of space and
it takes a while if you download everything at once. But in my experience
it has never been a problem. I must test build every package that I modify
so I need the sources anyway.
And there's a lot of value in the history. I often do "git log -p setup.py"
or "git log -p Build.PL" to discover new dependencies introduced by a new
upstream release.
FWIW my Kali work directory contains 200 repositories (and "linux" is one
of them) and takes about 6 Gb. Hardly a problem with the size of current
harddisk. We use gbp import-orig and pristine-tar.
> c) Upstream tag management
> The KDE release team currently publishes tarballs with checksums
> and git/svn revisions to packagers before the actual release for
> build testing and early Q/A. So when we build the packages, there
> is no git tag yet that we could use to generate a tarball
> ourselves, we would have to parse the tarball list for the commit
> hash that was used to generate the tarball and base our packaging
> on that - or wait for the tags and loose the chance to give the
> release team pre-release feedback.
Again the upstream tarballs are sufficient if you use a workflow based
on gbp import-orig.
> Aside from the different workflow, I do like the tagging proposal with
> vendor/version as that did not yet come up in my discussion with the
> debian-qt-kde folks.
I wanted to have this discussion for a while, but when I learned of this
shared repository plan I decided to go forward thinking that it could be
useful in this specific case...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: