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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
