Re: RFS: scim-waitzar, libwaitzar (re-submission) Attn: Paul Wise
On Tue, Jan 6, 2009 at 4:02 PM, S'orlok Reaves <sorlok_reaves@yahoo.com> wrote:
> Packages uploaded to mentors:
> http://mentors.debian.net/debian/pool/main/l/libwaitzar/
> http://mentors.debian.net/debian/pool/main/s/scim-waitzar/
Review, replies below.
>> 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....
Good stuff.
>> 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?
Sounds about right.
Would it be possible to make the private/removed symbols not exported,
so that applications cannot link against them and dpkg-gensymbols
doesn't find them?
>> 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.
Are you able to ship the spec in the source package and generate
Myanmar.model from the spec at build time? Or ship a myanmar-spec
source package that builds and installs the the Model file?
> 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.
Ok.
>> 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.
Not a deal-breaker, feels icky though.
> 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.
1.2Mb * 13 arches * ??? mirrors adds up to a lot. Maybe you could drop
the docbook source from the binary package?
I really hope that multi-arch addresses this issue at some point;
> 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?
I don't know enough about copyright to answer this correctly; I agree
with your feeling though.
Other stuff:
libwaitzar:
debian/README doesn't appear to be nessecary or should be moved into
the upstream README?
In debian/watch, [.] is just like \. but slightly longer.
It appears that the GNU GPL v2 and Apache 2.0 licences are
incompatible (GPLv3 is though):
http://www.fsf.org/licensing/licenses/#apache2
http://www.apache.org/licenses/GPL-compatibility.html
scim-waitzar:
debian/README doesn't appear to be nessecary or should be moved into
the upstream README?
Should you add ttf-sil-padauk to Suggests?
http://wiki.debian.org/Proposals/CopyrightFormat
need to handle DEB_BUILD_OPTIONS="parallel=n" in debian/rules, see
policy for an example.
In debian/watch, [.] is just like \. but slightly longer.
I note that you ship waitzar_users_guide.pdf instead of generating it
at build time, wouldn't it be better to generate it? Not sure I like
how you put all the images in a tarball instead of a subdirectory
either.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: