Re: upstream "debian" directory
On 03/14/2014 10:48 AM, Jochen Topf wrote:
> One major issue seems to be the question of a "debian" directory in upstream
> repositories. Upstream maintainers like it but it is a bit of a hassle for
> Debian package maintainers.
> Currently I know of three options:
> 1. Francesco has proposed to give the "debian" directory in upstream a
> different name and use a "make debian" target or so to create a symlink
> to it when needed.
> 2. Andreas has proposed to have it in a special git branch in upstream.
> 3. It can stay in place and we try to keep it in sync as much as possible
> with the "debian" directory in the official Debian repository. That's
> the way Sebastiaan and I just went with the osmpbf package.
> With options 1 and 2 Debian maintainers basically just don't see that upstream
> debian dir and can do their own thing. No hassle with keeping the different
> "debian" directories apart. But they might overlook changes in upstream debian
> configurations which might be important. In case of option 2 those changes are
> probably slightly more difficult to see than in option 1. On the other hand
> option 2 doesn't rely on a symlink and specific scripts or makefiles to do the
> On the other hand with option 3 we can use git tools ("git diff" for instance)
> to easily see changes and keep everything in sync.
> I don't have enough experience with all this to have a real opinion here.
> Anybody else? Opinions? Suggestions?
In an ideal world there is no need for upstream to maintain the debian
directory, leaving that to the Debian maintainers. But with the
increased popularity of Debian based distributions it's a fact of life
that upstreams do.
In my "grand vision" for the Debian GIS team we collaboratively maintain
the Debian packaging for Debian and its derivatives. Where "we" is
Debian, its upstreams and derivatives. We're not at the stage yet where
upstream and derivative developers maintain their changes for the
packages in the Debian GIS git, but we've solved the membership issues
with the additional Alioth project admins. It's now quite easy to join
the team and get access to the VCS repositories. The documentation of
best practices for collaboratively maintaining the package is still a
work in progress.
When upstreams incorporate the changes to the debian directory from the
official Debian package I'm not that opposed to having the debian
directory in the upstream source too. As long as responsibility for the
resulting packages is properly reflected by using different Maintainer
and Vcs-* control fields.
I'm quite happy with the way we worked on the osmpbf package here, and
how we're working with QGIS upstream in a similar fashion, although the
collaboration with QGIS is not as direct as in this case.
The cleanest approach to sharing a common debian directly where the
official Debian package is the lead is option 2 in my opinion, but this
requires a different workflow than upstream and Debian are using currently.
Option 1 is also nice to still have the ability to build debian packages
from the upstream source without including a debian directory that
should only live in the official Debian package tree. This is an
approach used at one of my past employers to produce debian packages for
our in-house softwar, except we didn't rename the debian directory
because that's where the Debian packaging tools expect to find the
required packaging information.
In fine with sticking to option 3 for the time being. It's not such a
big hassle, only a bit inconvenient.
GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1