[ Please reply to -mentors at least ] On Fri, Nov 28, 2008 at 5:37 PM, S'orlok Reaves <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
