Re: Standardizing the layout of git packaging repositories
Thorsten Glaser writes ("Re: Standardizing the layout of git packaging repositories"):
> On Fri, 15 Aug 2014, Russ Allbery wrote:
> > I want to be able to check out a git repository and do packaging work and
> > an upload, without having to pull any external artifacts from somewhere
> > else.
Yes. dgit does not solve that problem, but I think in principle it
would be possible for it to do so.
But that's not the only goal. Others:
* Given only the source package name and suite name I want to be able
to fetch the source code for a package in a form that means I can
immediately work on it in git, build it, etc.
(dgit currently solves this problem)
* I can maintain a long-term local branch with a modified version of
a package, in git, using standard git operations.
(dgit currently solves this problem)
* I can do an NMU which involves changing either the Debian
packaging, or the upstream source, or both, without having to think
about the maintainer's workflow.
(dgit currently solves this problem but produces
not-the-most-helpful-possible output for `quilt (3.0)', and leaves
you to do a couple of things by hand eg emailing the BTS with the
NMU diff.)
* I can straightforwardly integrate a new upstream tarball.
* I can straightforwardly integrate a new upstream git branch.
(I think git-dpm has tools for this; dgit has no support for it.)
> This does not work in Debian: you always need the .orig.tar.* file,
> at least for the upload, for non-native packages.
If you aren't doing a new upstream version, you do not need to upload
the .orig.tar.gz. It needs to be listed in the .dsc but that doesn't
mean actually has to be on your computer - since the information about
it in the previous version's .dsc is sufficient for that line in the
new .dsc.
In order to generate the correct diff etc. you need the _tree(s)_
corresponding to the .orig*.tar but in principle those could be
provided as git tree objects somehow.
> Actually, most of the time when working, you don’t even really need
> a VCS repository, I found out… (I’m now keeping many less packages
> in a VCS than before).
This comes to the final goal which is:
* People who want to continue to live in the stone age don't notice
that everyone else is using fusion-powered warp drives.
(This is a design goal of dgit.)
Ian.
Reply to: