Anyone good at packaging a library?

[Alexander Schmehl]

Hi!

* Reinhard Tartler <siretart at tauware.de> [060128 16:40]:
> > I was about to package squirrel lang (ITP#344496), needed for the
> > upcoming release of ppracer (and probaly other packages, too).
> > [...]
> > Could you help me with that, please?
> Yes, could you check in our svn what you have done so far, I'd happily
> take a look at this. (Although I don't claim to be an expert regarding
> libraries).

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).


Damn, I commited it by accident to pkg-games/squirrel/squirrel (instead
of [..]/packages/squirrel)... Could anybody please explain me, why the
folowing doesn't work to remove the wrong directory?
alex at vinyamar:~$  svn delete -m "Deleting wrong submitted dir"svn+ssh://svn.debian.org/pkg-games/squirrel/*   
svn: No repository found in 'svn+ssh://svn.debian.org/pkg-games/squirrel'


> 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 ;)


> 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).


> > 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).


Yours sincerely,
  Alexander

-- 
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20060128/18f23a68/attachment.pgp