Anyone good at packaging a library?

Thu Feb 2 13:22:46 UTC 2006

On Sun, Jan 29, 2006 at 04:10:50PM +0100, Reinhard Tartler wrote:
> I've seen that upstream does not even try to provide a shared library.
> (Is he interested in shared libraries at all?).

I didn't check anything at all, but I have my own static library, which should
stay static at least for now, because the interface is not stable, and I don't
want to get into the versioning mess that comes with dynamic libraries.
Perhaps upstream here feels the same about it.

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

Good point, when others start using the lib, someone will have to put up with
the versioning stuff.  Allowing many forks is much worse.

> > > > 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?

I'm not a DD either, and I may be just as clueless, but I think you are right
for the wrong reasons. ;-)

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

Indeed.  And the license does not prohibit it, so that should be fine.

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

I'm pretty sure it's possible to change them with a hex-editor or so.  Of
course it wouldn't be a very comfortable way, but it would work.  Also, I
expect that it will be possible to copy-paste the whole thing into something
else and edit that.  If not, use pdftotext on the generated pdf. ;-)  (Or
strings will probably give you the text, I don't know the CHM format at all)

In short, it is possible to create derivative works, it's just not very easy.

> But I don't see why there cannot be a free CHM editor at all. 

What the ftp-master seemed to claim was that it should be in contrib until
there is a free CHM editor, not that that couldn't exist.  I claim that he's
wrong, and that the fact that modifications are allowed is enough.[1]

Of course I am in the NM queue and he is an ftp-master, so if we can't come to
an agreement about it, I suppose his opinion is more important than mine. ;-)

Thanks,
Bas

[1] This means that DRM-encumbered documentation licensed under a free license
is no problem for the DFSG.  I think this is correct.  I also think this needs
changing.  However, Social Contract clause 4 says "In furtherance of these
goals, we will provide an integrated system of high-quality materials with no
legal restrictions that would prevent such uses of the system."  This could be
interpreted to imply "We will not put DRM'd stuff in Debian".

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.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/20060202/89fd231a/attachment.pgp