Re: Bug#322282: ITP: swapspace -- Dynamic swap space manager
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
Reply to: