On Thu, Aug 18, 2005 at 03:28:39AM -0500, Peter Samuelson wrote: > You've got it. That was the point of contention. The real objection
Thanks for a lucid explanation, and my apologies for a late followup. > 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. That makes sense. We really only care about the Debian packages here, but somebody else might want changes for e.g. a Fedora version. I've built it as a native package so far merely because it was enough to suit our needs and anying else was best left to someone more familiar with Debian packaging. From our point of view it will remain a Debian package with an option to install on other GNU/Linux platforms. That does not mean it has to be a real Debian-native package. I do see your point about territoriality. I would assume that some packaging changes that flowed logically from upstream changes, such as the recent deletion of the TODO file from the documentation, are not worth bothering the Debian maintainer about--better to make the change and be done with it. Conversely I'd trust the maintainer to make any changes that were valid for all systems, and apply good sense in doing so. I normally notify people when I modify their work, regardless of who owns the repository, to avoid not just unnecessary hard feelings but also merge conflicts and choices that the other would have made differently. What matters most on our end is the ability to roll up-to-date Debian packages during development--i.e. containing both the very latest working packaging and the source code we just modified--even if slight changes to the packaging are required just to keep things working. > 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. No problem there; once again, we have no intention of including a debian/ in any tarballs. It was only there so far because (1) the Debian tools generated tarballs with debian/ included, and (2) people might want to roll Debian packages for themselves. Otherwise, the only issue is as described above--that I'd like to have the packaging and the source code in the same repository to minimize communication latencies. Jeroen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
