[Pkg-crosswire-devel] Progress: sword 1.5.11-based package now available in my PPA, please test it!

[Daniel Glassey]

On Sat, Jan 24, 2009 at 11:48 PM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
> Daniel Glassey wrote:
>> On Sat, Jan 24, 2009 at 10:03 PM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
>
>> Great work :)
>
> Thanks!
>
>> debian/rules
>> DEB_DH_MAKESHLIBS_ARGS_libsword6 := -V"libsword7 (>= 1.5.11-1)"
>> DEB_SHLIBDEPS_INCLUDE_libsword6 := debian/tmp/usr/lib
>>
>> that should be DEB*_libsword7
>
> Yes.  Among all those 6 becomes 7 edits, I missed a couple!  Can you
> explain why we need the (>= 1.5.11-1) type of qualifier at all?  What
> purpose does it serve?  Is there documentation on using these variables
> somewhere that I should have read?  Also, doesn't this duplicate what
> libsword7.shlibs does??  As you can tell, I'm probably a bit muddled
> about how this stuff works.  Can you educate me?

Yes, I forgot, you don't need to worry about the shlibs file beyond
what is in debian/rules because CDBS handles it now.

Afair the (>= 1.5.11-1) is for safety in case of packaging problems or
a bug coming up in 'unstable' that compromises binary compatibility.

The format is in:
http://www.uk.debian.org/doc/debian-policy/ch-sharedlibs.html#s-shlibs

>> I think one of the complaints somewhere was that the lib wasn't built
>> with icu support enabled so let's add the configure option --with-icu
>> which is off by default
>
> Yes.  I wanted to try a "get it to build at all" package first, and then
> start on Refdoc's list of requests (except I moved the CGIs, because
> that was so trivial and I'm somewhat security-aware).

Fair enough :)

>> debian/diatheke.README.Debian
>> I've never tried this but that is my best guess of what to name the
>> file to be a README.Debian just for the diatheke package
>
> Yes; I was hoping someone else might volunteer to write the text, but
> I'll just go ahead and do it.

Thanks

>> debian/control
>> package libsword7 should 'Replaces' libsword6
>
> Should it really?

See other thread

>> diatheke - let's change the Recommends of apache2|https to Suggests
>
> Actually, now we're not installing any CGI code at all, let's just
> remove it completely!

Yes. It should be mentioned in the README.Debian but you are right, no
need for the dependencies now.

>> debian/copyright
>> let's update the copyright date to 2009
>
> OK, can do.  Upstream does not seem to have done so, though.  Their
> LICENCE file shows 1996-2006, and I see nothing with a 2009 copyright in
> the 1.5.11 source tarball at all.  The usual expectation is to copy the
> upstream copyright notice to debian/copyright, isn't it?  Should
> packagers really be changing/correcting legal documents created upstream??

Yes, that makes sense.

>> debian/diatheke.dirs
>> we can remove usr/lib/cgi-bin since we aren't installing anything there now
>
> Actually we can remove much of the .dirs stuff, I am almost sure...
> usually you only need debian/*.dirs for installing empty directories,
> dh_install will do the right thing automatically for directories it
> installs files into, unless I am very confused... which is possible!
> I'm going for a "minimalist" aproach on ./dirs files this next time,
> let's see what breaks!

I'm just as likely to be confused (or influenced by previous install behaviour).
Afair (vaguely) it is also needed for dpkg to remove directories if
they are empty and aren't used by any packages.
Have you ever used piuparts? It is supposed to be good for testing
those kind of things.

>> debian/libsword7.shlibs
>> I think that should be
>> libsword 7 libsword7 (>= 1.5.11-1)
>
> Probably: again, can you please explain what this is really doing for us
> -- what breaks if we delete that debian/libsword7.shlibs file, and why
> is this info both here and in debian/rules ?  The examples in the
> dh_makeshlibs man page do not include the -n suffix, BTW.  I strongly
> suspect we can remove debian/libsword.shlibs and let the rules file and
> dh_makeshlibs "do the right thing" for us... can you confirm that?

As above, it shouldn't be necessary now.

>> debian/libsword-dev.dirs
>> I think these dirs should be added
>> usr/include
>> usr/include/sword
>> usr/lib/pkgconfig
>
> See my comment above about dh_install doing this for you... we should
> definitely check on this, since we are apparently looking at the use of
> debian/*.dirs (and to a lesser extent debian/*.shlibs) differently!

Needs to be checked as above.

> For this kind of rapid dialogue (which is really good to have!), maybe
> we should be using IRC... I'm in #sword on Freenode right now (my nick
> is jmarsden) ...

Indeed, hopefully I can get on there tomorrow eve(UK time), too late now ;).

Thanks,
Daniel