On Wed, Mar 01, 2006 at 03:52:04AM +1100, skaller 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. > However there is a reason, it is political, it is > relevant -- it convinced me anyhow :) I also initially > produced a native package.
Thank you for this explanation. Although I still have some issues with it, it seems I should build infrastructure for building source packages. (Earlier, one just needed dpkg-source -b; now it seems there must be some script or makefile target to construct a fake .orig directory and then build the source with that.) It feels funny that I have to make a dummy "pristine" source for the Debian project while I've been releasing the "debian-specific" source outside Debian for ages. > 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. Okay, this seems to be the same (probably?) as the "transparent NMU" thingy. It is imaginable that we can derive some benefit from separating the "source distribution" into different bits like packaging and everything-else -- maybe less stuff to upload, although it won't make any difference with project sizes like this... But I still wonder -- if it is beneficial to separate the packaging from the other source, would it not be beneficial to separate other components of the source that are not circularly dependent on each other? Is it, for instance, a problem that if the _documentation_ of a piece of software changes, the whole .orig.tar.gz gets updated? Is there something special about packaging information that makes it especially vulnerable to separate changes, even when the packager and the upstream author are the same person? And related to that: > 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. I've been living with this for a long time, because I've been maintaining my software projects as native Debian packages for a long time. I don't know whether my experience has any weight in this, but for me, this has never been a problem. I have automated release scripts for these pieces of software, so it doesn't really bug _me_ even if the version is bumped three times a day. (And packaging-related issues have very seldom been the only cause of a new version -- but maybe that's going to change if I get sponsored...) And I can't come up with a reason why it would bug anyone else. > 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! I use version control for my projects, both native and non-native. (BTW: I use darcs but not darcs-buildpackage, because dbp seems to be so rigid about how things should get done.) So I will get easily any version of the project I need... but in this case, there really has never _been_ such a thing as a non-debian source version, so it's much easier to just construct one from the real source, if it's really necessary. Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint: 0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
