[Pkg-zsh-devel] Packaging best practice when upstream git contains more directory levels than the upstream tarball?

[Axel Beckert]

Hi,

for quite some while now I'm wondering what's the best practice to
maintain a package in a git repo if upstream uses a git repo, too, but
that has at least one directory level more than the official upstream
tarball.

I prefer to base my packages on official upstream tarballs for several
reasons (see below), but having the upstream git repo as remote in
your packaging git repo also has some advantages.

Unfortunately git has not yet a narrow clone like Subversion does
(i.e. with git you are not able to just clone a subdirectory instead
of the full repo), so things seem to get really complicated if the
upstream git repo contain more directory levels than the upstream
tarball.

So far the problem. Now to the advantages of both ways:

Upstream tarballs are preferable because:

* It's use is recommended in the Developer Reference
* It's clear how the tarball was generated -- built by upstream and
  downloaded
* Distributions which build the software on package/port installation
  time (like e.g. FreeBSD and Gentoo) rely a lot on the Debian
  mirrors -- but only if we use the original upstream tarball.(*)

(*) Even if some may argue that's somebody else's problem, I think
    it's a not so unimportant argument.

Tarballs built from a git repo which includes the upstream git repo as
a remote git repo are preferable because:

* They may include more files you possibly need for using
  automake/autoconf foo or to rebuild other stuff which is prebuilt in
  the official upstream tarball.(**)
* You can use git bisect to see where upstream introduced a bug.
* You can easily produce packages of upstream snapshots.

(**) From my current point of view this is the only really problematic
     issue and if such an issue is not present, using upstream
     tarballs is preferable.

In ran into this dilemma when I packaged a git snapshot of screen for
experimental. Nevertheless I noticed the fact that it really can be a
problem only when looking closer at the packaging of zsh -- which
currently has issues similar to the one marked with (**), but without
the "one more directory level" component. (I though believe that we
can do the balance between both worlds with zsh. :-)

My current "solution" (well, more a workaround than a solution) for
packaging screen is to use upstream tarballs and keep a clone of the
upstream git repo in a separate git working copy. (A separate branch
would also do it, but that would be like having clones of two
completely different git repos in two branches of one git repo.)

Another idea which I had was using git submodules for whatever is in
the upstream tar ball, but I ran into non-obvious problems already
while just imagining with it.

Anyone else ran into this problem? Anyone has found a better solution
-- or a better workaround? :-)

Maybe also the git-buildpackage-alike workflow in my head
(git-import-orig, debuild -uc -us, pdebuild, git-builtpackage
--git-tag-only) keeps me away from seeing the wood for the trees...

P.S.: If anyone is interested in helping to maintain screen in Debian,
have a look at this RFH: http://bugs.debian.org/654116 -- TIA :-)

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5