Re: RFS: b5

[Panu Kalliokoski <atehwa@sange.fi>]

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:	panu.kalliokoski@helsinki.fi, +35841 5323835
technical contact:	atehwa@iki.fi, http://www.iki.fi/atehwa/
PGP fingerprint:	0EA5 9D33 6590 FFD4 921C  5A5F BE85 08F1 3169 70EC