Re: RFS: scim-waitzar, libwaitzar (re-submission) Attn: Paul Wise
[ Please reply to -mentors at least ]
On Fri, Nov 28, 2008 at 5:37 PM, S'orlok Reaves <sorlok_reaves@yahoo.com> wrote:
> I have split libwaitzar off from scim-waitzar and built a separate package:
> http://mentors.debian.net/debian/pool/main/s/scim-waitzar/
> http://mentors.debian.net/debian/pool/main/l/libwaitzar/
Cool, see below for a review of libwaitzar (all I have time for right now).
> ...but I cannot do the same for KaNaung. There are several reasons for this:
> 1) KaNaung was developed specifically for Windows. Most of the code I borrowed had to be modified up before it would compile under Linux.
> 2) I used SVN revision 700 of kanaung's source; the upstream developer has since closed the source for later revisions. (I have written permission of the copyright holder to use the newest source of kanaung, but I chose to only include kanaung code which is covered under the GPL.)
Oh, that sucks.
If you are able to get later but still GPLed revisions from upstream,
that might be a good idea.
It might be a good idea to produce a kanaung fork with a new name and
focusing on keeping it suitable for use in a free software
distribution.
Then you could package the kanaung fork separately.
>> Is scim-waitzar directly derived from the Windows WaitZar?
>> The user manual seems to indicate that you relicensed parts of it
>> from BSD to GPL, which you usually aren't allowed to do unless
>> you wrote them.
> Yes, I wrote both scim-waitzar and Windows WaitZar. In order to make the line
> clearer, I removed all of the Windows WaitZar code from scim-waitzar and put
> it into the libwaitzar package. The libwaitzar package is licensed under Apache
> 2.0, but please let me know if the licenses conflict and I will dual-license it.
According to the FSF, the Apache 2.0 license is compatible with the
GNU GPL 3 but not GPL GNU 2.
http://www.gnu.org/licenses/license-list.html#apache2
>> http://waitzar.googlecode.com/svn/trunk/release_1.5+_beta/Myanmar3.ttf
>> http://waitzar.googlecode.com/svn-history/r219/trunk/release_1.5/Zawgyi-One.ttf
>>
>> If these are DFSG-free and are Unicode fonts, you might
>> want to join the Debian Fonts Task Force and package them too.
> I'll consider it, but I've had a hard time contacting the developers of Myanmar3 and Zawgyi-One....
Thanks for the info. At least things have moved on since the days of
Burmese using ASCII and a special font. I think something like
khmeros.org would be a great way to promote adherance to Unicode and
other standards.
>> Please run "lintian -i -I" on your package
> I've fixed all lintian errors in both packages. Unfortunately, one warning remains:
> W: libwaitzar1: package-name-doesnt-match-sonames libwaitzar-1.0-1.0-1
> I've checked online, checked other debian packages...
You'll want to read libpkg-guide:
http://packages.debian.org/libpkg-guide
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
In your case, the SONAME is determined by libwaitzar_1_0_la_LDFLAGS.
A review of the packages:
The library...
There is one more lintian -i -I issue:
I: libwaitzar1: no-symbols-control-file usr/lib/libwaitzar-1.0-1.0.so.1.0.0
Please see these links:
http://wiki.debian.org/UsingSymbolsFiles
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
http://manpages.debian.net/cgi-bin/man.cgi?query=dpkg-shlibdeps
http://manpages.debian.net/cgi-bin/man.cgi?query=deb-symbols
http://manpages.debian.net/cgi-bin/man.cgi?query=dpkg-gensymbols
What is the preferred form of modification for Myanmar.model? Do you
modify it directly?
Is the transitional package libwaitzar-dev needed? Please note that
dev packages for libraries should be named libwaitzar-dev or
libwaitzarAPINUMBER-dev rather than libwaitzarSONAME-dev.
You should not ship README/etc in transitional packages.
Seems to me like you should merge libwaitzar1-dev into libwaitzar-dev.
With libraries, usually they are automatically installed and the dev
package description is the only one for human consumption. Therefore
the dev package should be written for a human and the library package
can be minimalistic (say just the last sentence of the current desc).
Similarly you probably don't need the upstream changelog in the library package.
Generally a static library isn't needed in distributions like Debian,
you might want to drop it. It should be shipped in the dev package
rather than the library package anyway.
The .so symlink should be shipped in the dev package but not the
library package.
About /usr/share/waitzar, it might be a good idea to version that
directory with the SONAME so that libwaitzar1 will be co-installable
with libwaitzar2 when the ABI changes. Alternatively, either compile
the model and text file into the library itself or maybe split it out
into a libwaitzar-data package.
Personally I would expect /usr/include/waitzar-1.0/waitzar to be
/usr/include/waitzar, since it is that way for most packages. Same for
the pkgconfig file.
Also, Makefile.in and any other generated files should not be stored
in your version control repository.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: