[Jeroen Vermeulen] > 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.
You've got it. That was the point of contention. The real objection here is debian maintainers who feel as though upstream is trying to usurp their authority over the contents of debian/. And the practical result that if the two sets of contents get very far out of sync, the diff between them is a lot uglier than the diff between "no debian dir" and "the debian release" would be. (The ugliest part being debian/changelog, which will diverge by absolute necessity unless the package is *truly* debian-native.) It's not as though it's *difficult* to blow away a directory and insert your own, as a debian maintainer. That's why, though I support tarball separation, I have to assume these wild overreactions are mainly about territoriality. Now for why these people, even if overreacting, are mainly right: If you think your package really is only useful on Debian-like systems, it may be ok to treat it as a debian-native package - that is, not to bother releasing "upstream" tarballs but only Debian source packages with tarballs in them. However, it sounds like your package really could be useful on other Linux systems, in which case it'll make everyone's workflow simpler in the long run to decouple the upstream and Debian release processes. And in the latter case, it doesn't make much sense to stick debian/ inside the tarball, even if the Debian maintainer is on your same team. By doing fully non-native Debian releases, you simplify the job of doing arbitrary Debian-specific patching and re-uploading - and sometimes this re-uploading has nothing to do with your package per se, but is more of a "recompile against these newer libraries" or "upload to unstable instead of experimental". It would be annoying to have to release a whole new upstream tarball just for stuff like that. Peter
signature.asc
Description: Digital signature
