[Pkg-ime-devel] RFS: scim-waitzar, libwaitzar (re-submission) Attn: Paul Wise

[S'orlok Reaves]

Hope you all had a good holiday season. I've finally gotten some free time, so I've addressed & implemented (most of) the changes you (Paul) suggested. Sorry for such a long turnaround-time; I've had a lot of Debian policy reading to do. ;)

Packages uploaded to mentors:
http://mentors.debian.net/debian/pool/main/l/libwaitzar/
http://mentors.debian.net/debian/pool/main/s/scim-waitzar/


First, the discussion questions:

> If you are able to get later but still GPLed revisions from
> upstream, that might be a good idea.
The KaNaung library is used to convert WaitZar's words from one encoding to another. Every time it I link in a new version, I have to manually check all 2426 of WaitZar's words for conversion errors. I'll eventually automate this task, but for now, SVN version 700 works, and I don't have time to check any later version. 


> 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.
KaNaung is a big library, so I am hesitant to fork it. The good news is, I've talked to the developer of KaNaung, and he's said he's not against open-sourcing the project; he just doesn't want to maintain the code & programming. He is much more knowledgeable than I am about encoding, so my goal is to keep him in the loop (perhaps I can offer to deal with packaging and bug reports?) Consider this a WIP....


> Thanks for the info. At least things have moved on since
> the days of Burmese using ASCII and a special font. 
I heartily agree; thank goodness!


> I think something like khmeros.org would be a great way to 
> promote adherence to Unicode and other standards.
Building a community is the best way; I agree. I'll float the idea on the Myanmar IT Pros web site after the first release of scim-waitzar comes out.


And now, for the package fixes:

> In your case, the SONAME is determined by libwaitzar_1_0_la_LDFLAGS.
Thanks, I finally got it. (Fixed)


> I: libwaitzar1: no-symbols-control-file
> usr/lib/libwaitzar-1.0-1.0.so.1.0.0
> Please see these links...
I read as much as I could, and here's what I did:
 - Ran dpkg-gensymbols to get a list of symbols in my library
 - Removed all "private" class methods, and all methods that I use privately (i.e., templated global methods).
 - Removed all symbols from the kanaung library (except convertFont).
 - Stored the resulting symbols in libwaitzar1.symbols
This got rid of the warning, but I am very inexperienced at symbols versioning --is this sufficient?


> Seems to me like you should merge libwaitzar1-dev into libwaitzar-dev.
Good call. (Done)


> With libraries, usually they are automatically installed...
> ...and the library package can be minimalistic (say just 
> the last sentence of the current desc).
Done.


> Similarly you probably don't need the upstream
> changelog in the library package.
Done. Since the two changelogs for libwaitzar were nearly identical, I simply removed upstream's changelog from both libwaitzar1 and libwaitzar-dev. 


> Generally a static library isn't needed in
> distributions like Debian
Done. I also removed the .a file from the scim-waitzar package.


> What is the preferred form of modification for
> Myanmar.model? Do you modify it directly?
..and..
> About /usr/share/waitzar, it might be a good idea to
> version that directory with the SONAME so that 
> libwaitzar1 will be co-installable
Myanmar.model is at version 2. The file is generated from a full specification which itself is voted on by the Myanmar community. This process takes 3 months. Every new version of the model completely obviates the old one, and generates a major version change.
mywords.txt is updated with every new release of libwaitzar. It only affects about 1% of all Myanmar words, and is intended to fix mostly cosmetic changes; it is NOT a problem if this file gets constantly over-written.
That said, I decided to put both files into the /usr/share/waitzar/model2 directory. The only people who will want to use an outdated model are those who are doing research in the field; they will not care about mywords.txt in general, and will probably load their own local models anyway.
I expect all future ABIs to be backwards-compatible with the file format of Myanmar.model, so I think this solution is sufficient.


> The .so symlink should be shipped in the dev package but
> not the library package.
Done.

 
> 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.
Done and done. (But please double-check this.)



> Also, Makefile.in and any other generated files should not
> be stored in your version control repository.
For now, I would like to leave them in, for my own reasons. If this is a deal-breaker, let me know.


And now, some new issues:

1) There's a lintian warning:
I: scim-waitzar: arch-dep-package-has-big-usr-share 1216kB
...Please let me explain. Scim-waitzar ships a 600KB user's guide, and the 630KB docbook source needed to compile it. This USED to be offset by a 838KB static library file (the dynamic files total only 563KB), but I removed the static library file, as you recommended.
I could solve this warning by making a -common package, but I really don't see the need. Is 1.2MB * (total_architectures) of server space too much? I only found this warning by slimming down the rest of the install.
Of course, just say the word if this is a big deal.

2) The copyrights in the files all say 2008, since all changes to them since my last RFS were effectively cosmetic. I feel the copyright rests in 2008, but I don't know the legal details. Is it better to change the date in debian/copyright? In all the source files?

3) I kept both packages at version 1.0.0, since these were not heavily distributed and only cosmetic changes were made.


Thanks again for helping me through these rookie mistakes. I truly am grateful for all the mentoring and guidance.
-->Seth