On Tue, 2006-02-28 at 17:12 +0100, Thijs Kinkhorst wrote: > It's your call, but since making them non-native is not really that much > more work, I'd recommend doing it that way.
It can be quite a lot more work if you have powerful scripts that can generate the required meta-information during the build process (since that requires no work .. once the scripts are got right :) However there is a reason, it is political, it is relevant -- it convinced me anyhow :) I also initially produced a native package. Debian tries to maintain standards of packaging quality. This may mean someone else may wish to fix bugs in your packaging. If your packaging is part of the source tarball, that requires editing the tarball. If the packaging is separate, the tarball doesn't change, only the packaging. This is true, even for bug fixes to the source itself: they're diffs in the packaging, your tarball remains invariant. Related to that -- if the packaging is wrong, and you, the upstream author, fix it .. you've just produced a completely new version of your product because you've changed the contents of your tarball. HOWEVER, you should note that you can STILL generate the debian packaging if you want, as a convenience. Just put it in a directory 'initial-packaging' or something. Then you can make the debian package by just copying it .. and you can still patch that copy without changing the tarball. Next release -- get the initial-packaging right! -- John Skaller <skaller at users dot sourceforge dot net> Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
