[Pkg-crosswire-devel] get-orig-source changes (was: Re: [Branch ~pkgcrosswire/libsword/main] Rev 44: * debian/rules: )

[Jonathan Marsden]

Dmitrijs Ledkovs wrote:

>> must be documented in the resulting source package. Detailed 
>> information on how the repackaged source was obtained, and on how
>> this can be reproduced must be provided in debian/copyright.

We can do that better that we did... OK, done, committed, pushed to
lp:~pkgcrosswire/libsword/main  :)

>> It is also a good idea to provide a get-orig-source target in your
>> debian/rules file that repeats the process, as described in the
>> Policy Manual, Main building script: debian/rules."

That's what it already does.  It grabs the latest tarball and repacks
it.  That is what we did.  You can repeat that process by invoking the
rule.  And this is officially a "good idea", not a requirement.

> So my change actually focuses on the reproducibiliy. ...

Hmmm.  I think that's going overboard... it might have been good to
discuss it first, or push to (yet another) new branch before committing
the change to the main branch?

As I see it, repeating the process is fairly pointless on the current
codebase.  Repeating it on a new upstream codebase is exactly what is
needed to start packaging that new upstream release.  Seeing what it
does (so you can check that it doesn't do anything bad!) is also important.

> Now image Squeeze is released and it has sword-1.6.0+dfsg-1 in it and
> by this time sword has released 1.7
> User want to repeat the steps we did to recreate the tarball and
> instead of ending up with the expected sword-1.6.0+dfsg tarball she
> will end up with a much newer upstream release.

The user (really a packager/MOTU/DM) can easily see exactly what we did
from reading debian/copyright, examining the get-orig-sources rule, and
check it by comparing the two tarballs (original and repacked) for any
given SWORD version, if they don't trust us.  Such a packager/MOTU/DM is
presumed to be pretty Debian packaging and command line competent anyway.

> So yes previous method was defaulting to fetch newest one. My change
> defaults to grab and recreate the same latest version as per the
> latest changelog entry.
> 
> Sorry about this. I'll try to seek more guidance on this one.

OK.  Meanwhile, I really think we need to focus better.  You suggested
that we get a 1.6.0 package out the door soon, and set a timeline.  I
agreed and suggested 7 days.  But now, you seem to be making somewhat
speculative changes (concerning a "good idea", not a requirement) to
relatively hard-to-understand packaging makefiles, directly in the
libsword/main branch and with no discussion, and you are spending time
on compiler warnings and testsuite failures... none of which is needed
to get 1.6.0 packages ready for upload.

Can we try to stick to doing what we need to do to get a 1.6.0 package
ready for upload into Debian unstable in about 4 more days?  After that,
testsuite improvement and compiler warning elimination and whatever is
great, if you want to do it -- but let's get the job done first :)

Jonathan