Anyone good at packaging a library?

[Reinhard Tartler]

Am Samstag, den 28.01.2006, 22:02 +0100 schrieb Alexander Schmehl:
> Thanks very much.  I just injected it.
> But so far I didn't did that much... (acutally, just a watch-file, a
> changelog and bit of control; before I could finish that (and rules) I
> stumbeled about the mentioned problems).

> > The buildsystem upstream currently has is, hm. let's say quite
> > improvised. It shouldn't be that hard to convert it to automake and co.
> 
> Yes, please do so.  I didn't did anything similar, yet ;)
> 

Ok, I committed a configure.in and Makefile.am files which produce a
working binary in sq/sq.  (Caveat: I had to symlink sq.c to sq.cpp to
persuade automake to use g++ instead of gcc. Anyone an idea to do this
in a less crackfule way? please just fix it).

I've seen that upstream does not even try to provide a shared library.
(Is he interested in shared libraries at all?). So I didn't do that in
automake either, and just produced a libsquirrel.a and a libsqstdlib.a

Now the interesting point: What should be inside a potential shared lib,
so that e.g. the next ppracer package could profit from that?
libsquirrel.a, libsqstdlib.a or both?



> > Regarding the soname: Lets invent one, and propose to upstream to adopt
> > it. If he doesn't, I think we can maintain a 'debian specific' soname,
> > libsquirrel-debian.so.0 or something like that. That way we will get
> > binary incompatible to other distributions, though.
> 
> Well, about binary incompatible that's shouldn't be a problem yet.  The
> only package I know about, which could use squirrel, would be ppracer
> (and that has it's own squirrel version in it's tarball).

Ah, I thought something like that. So because squirrel does not provide
a shared lib, other project start 'forking' it by including a local copy
of it. This is a bad approach for a number of reasons. I think we should
approach upstream and convince him adopting automake and introduce an
'official' soname, so that other projects can rely on that.


> > > PS:  Other problem of the package would be the documentation.  It's
> > > provided as Windows CHM-File, and AFAIK there is no free editor for that
> > > (only viewers).  So the documentation would need to stay in contrib,
> > > even if upstreams supplies usable pdf documentation - damn.
> > errm, why contrib? I think if the documentation itself is not free, it
> > should go to non-free. If it is free, but the only problem is that we
> > cannot create a pdf from the CHM file, I think we should place both the
> > CHM File and the pdf to a source tarball and distribute that in main.
> > That way we included the source in the 'preferred form for
> > modification'. We cannot, however, provide means for editing that, which
> > is sad, but should not be a problem for main, I think.
> 
> Because the ftp-master, sitting next to me told me so ;)
> Reason:  Since ther's no free tool available to edit them, it's
> impossible to create derivade works.  Therefore they need to go to
> contrib:  They are free, but depend on a tool that doesn't exist in
> Debian main (at least until such a tool exist).

Hm. I'm not a DD, but could a person with more clue than I have point me
to a discussion for this? DFSG rule 3 says:

Derived Works 

The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the
original software.

The CHM file is the preferred way for modifications and there is no
doubt that this is considered the source for it. However I don't read
DFSG3 that it is required that Debian provides tools for creating
derived works. It says only that the licence must not prohibit doing so.

You say that it is impossible to create derived works. I don't think
that it is really impossible. It is not possible to do that using the
tools which debian currently provides, (Well, perhaps there is some
(semi-)free CHM editor which works with wine, which debian
distributes)). But I don't see why there cannot be a free CHM editor at
all. 

-- 
Reinhard Tartler <siretart at tauware.de>