Re: Bug#322282: ITP: swapspace -- Dynamic swap space manager
On Sat, Aug 13, 2005 at 11:16:36AM +0200, Henning Makholm wrote:
> If you have nothing against a clear separation between the upstream
> source and the Debian packaging, when why are you objecting when I say
> you should have one?
I am still not objecting to a clear separation per se, just to having
the two in separate revision control systems when I can offer a
prospective Debian maintainer those facilities including branching and
tagging and easy merging of patches. I figured, and several other
Debian developers have confirmed this by now, that what I'm suggesting
would be more, not less, convenient for the Debian maintainer. That was
one of the two reasons why I suggested it, and it has worked well for the
maintainer of another Debian package I'm the upstream author of.
The other reason in this case is that upstream testing is always done as
a Debian package, so this way the two can be kept in sync more easily,
more immediately, and more consistently--which makes life on our end a
bit easier as well. Like I said, we build and run the Debian package,
not some (currently nonexistent) upstream version.
When it comes to separation, I should also add that the project does have
the usual separate non-Debian build setup. But that is mostly because
(1) it is the proper way of doing things and (2) it may become relevant
someday--in that order. We don't use the autotools though, since those
probably wouldn't pull their weight at this stage.
> > but to me that is not necessarily the same as having disparate SCM
> > implementations for different parts of the same project.
>
> Huh? Is your Debian packaging stuff written in Scheme?
SCM stands for Software Configuration Management, a common term in the
software world for revision-control systems such as CVS and Subversion.
In our case it's Subversion, which I think is best described as "CVS
without most of the problems we hear so much about." Day-to-day use is
almost identical to that of CVS, except it caches checked-out files
locally so you don't need network access to get an overview of your local
changes.
> > To me, having a debian/ directory and branching off Debian release
> > branches from the trunk are examples of a clear separation.
>
> If the tarball you provide to packagers include a debian/ directory,
This is where we have our wires crossed: I'm still talking _only_ about
giving the Debian packaging a home in the same SCM repository. You'll
remember that I said this is, from our point of view, primarily a Debian
package and so the tarball is more of a byproduct. Whether the debian/
directory would go in there would be based entirely on what is the most
convenient for the Debian maintainer. I don't care either way.
As a secondary point, and this may have contributed to the confusion,
the Debian maintainer would never need to download a tarball since it
could come straight out of his own working directory. So even if it
did have that debian/ directory, its contents would be the exact same
packaging that he was about to insert in the first place--not somebody
else's or yesterday's version of his own. Another Debian developer was
kind enough to fill in the blanks for me
> > If it doesn't describe the process accurately, then please explain
> > how so that we can get this whole issue out of the way.
>
> How == don't ship any debian/ directory in the upstream source.
I guess I should have phrased that question in easier terms... But now
that someone else has answered it for me: when you say "don't ship any
debian/ directory in the upstream source," do I understand correctly that
you're _only_ talking about providing a tarball without the debian/
directory, not about how we provide upstream source otherwise?
If that is what you mean then I don't think we are in disagreement
whatsoever. It may seem an obvious thing to you, but remember that I am
not familiar with these procedures and have had to go on your
explanations.
> You can have one in your internal version control system if you think
> that is fun, just as long as your tarball generation script excludes
> it.
That's another point: we have no tarball generation script at the
moment. It wasn't quite necessary yet since debuild generated one anyway,
and there was never any intention of releasing anything that wasn't
identical to a simultaneously released Debian package minus packaging.
But naturally we can add one if it matters.
Jeroen
Reply to: