Re: Bug#322282: ITP: swapspace -- Dynamic swap space manager
On Wed, Aug 10, 2005 at 01:00:59PM +0200, Henning Makholm wrote:
> On the other hand integrating Debian's *packaging* infrastructure
> (i.e., the debian/ subdirectory) in upstream source cannot be
> recommended. It only creates trouble for developers when the policy
> and environment they are packaging for drift out of sync with your
> offer (as it will inevitably). Even in the cases where a Debian
> developer is himself the upstream author of some software, it is
> common that he maintains the Debian infrastructure separately from the
> upstream tarball.
In this particular case though, Debian is the primary environment for
the program. For us, taking the Debian parts out might be just as
awkward. Can't we use Subversion branches on the entire source tree
plus packaging, and do without separate distribution-specific patches
apart from that? We could branch when etch is released, for instance.
> The best way to be packager friendly as an upstream author is to
> provide a robust, portable build infrastructure with a configure
> script and flexible 'install' targets in the Makefile that behave like
> autoconf-generated ones. Keep autotools support files up-to-date when
> you release, and so forth.
So far we've avoided the use of the autotools. This is not meant to be
a portable program, although of course there's no telling if maybe
someday it will be.
> If you want, you can encourage packagers to submit patches for your
> makefiles rather than working around them in their Debian rules. Many
> packagers by default try to touch the upstream makefiles as little as
> possible, but that ought to be reversible if the upstream author
> requests so.
I would want that in any case. In fact it would not be a major problem
to provide subversion access to a Debian maintainer.
Jeroen
Reply to: