Re: RFS: libthai 0.1.9-2 (updated package)
On Feb 5, 2008 2:42 PM, Paul Wise <pabs@debian.org> wrote:
> Maybe libthai0/libthai-data shouldn't have any docs (README/TODO/etc)
> in them since those are mostly automatically installed, instead it
> should go in the -dev package and the -doc package.
OK. I'll fix that. In fact, the TODO file does not contain much
useful info. I may drop it in all packages. Just README and
NEWS should be enough.
> Good to see you are using a symbols file, mole says you need different
> symbols files for different arches:
>
> http://qa.debian.org/cgi-bin/mole/seedsymbols?pkgname=libthai0
I did check Mole before preparing the package. But, I decided
to ship a single file for all archs after consulting with a DD.
The archs that differ from the others are hurd-i386 and
m68k, and the differences are:
1. Deprecated symbols are not listed for the two archs.
2. Minimal version for the two archs appear to be 0.1.9,
while the others list 0.1.6.
3. For hurd-i386, some private symbols are added in the
symbols file.
I don't list the deprecated symbols because they are all
private. They first disappeared in 0.1.7, when internal
implementaion was rearranged, and then more were removed
in 0.1.8, by the explicit exporting..
Then, regarding the different minimal versions, hurd-i386
and m64k appeared to build and install libthai 0.1.9 as their
first versions. So, the symbols files generated by Mole look
like that. Then, when dpkg-shlibdeps checks the versioned
dependency on libthai, it will find (>= 0.1.6) from the symbols
file, which 0.1.9 already satisfies.
And for the excessive private symbols for hurd-i386, it's
obvious that listing private symbols is prohibited. Or it could
cause libthai to be pulled into some package's dependency
by accident.
Therefore, as libthai public API has never been changed
so far, and with the above reasons, I think it could be safe
to ship a single symbols file for all archs.
> I also note that the seedsymbols script indicates that some functions
> have been removed, but the ABI has not been increased.
As mentioned above, the removed symbols are all private.
The required symbols for normal apps that link with it are
all the same. If there would be ABI incompatibility, it would
be that the new version won't crash programs that happen
to have name clash with the private symbols. But it won't
break programs that depend on its published features.
> The -doc package installs stuff to /usr/share/doc/libthai0-doc,
> shouldn't it be /usr/share/doc/libthai-doc?
Ah, this is the relics of some historical change of the
package. I'll fix it soon.
> Your shlibs says >= 0.1.7 but the max version in your symbols file is 0.1.6.
The shlibdeps was bumped to 0.1.7 by Loïc Minier in 0.1.8-1,
because 0.1.7 is safer to link with than 0.1.6 (the etch
version), as many private symbols had been removed.
Meanwhile. the symbols file just reflects the fact that the
symbols are also available in the etch version.
If it's to be changed, I'd rather bump the versions in the
symbols file to 0.1.7 and ignore etch completely. Would
there be any drawback in doing so?
> I'm not sure what the machine-readable copyright proposal says, but I
> expected to see copies of the "this is GPL" blurbs from the source
> code in debian/copyright
I think the blurb under License: field is for additional
information, when there are additional terms to the usual
license, such as exceptions or where else the files are taken
from, etc.
For the standard "This program is free software..." text,
I think it's equally right to either add or to not add them.
To be sure, I can add them as you suggest anyway.
> I don't see filenames in the Licence line in the copyright proposal.
I took that example from some existing packages, like
libwebkitgdk.
OK, to conform to the proposal, I'll change it back.
> I think there are supposed to be commas between the authors and each
> author should have their own copyright years?
I think we need to clarify what "each copyright holder" in
the proposal means:
"Suggested format: free content, one line per copyright holder"
And in the "Complex example", for the boing.wav paragraph:
Copyright: (c) 2003 by David White <davidnwhite@optusnet.com.au> and the
Battle for Wesnoth project
(c) 2006 Sam Hocevar <sam@zoy.org>
Here, there are two entities for the "copyright holders",
one with many people, and the other with a single person.
In case of libthai, the copyright holders are listed as a single
team in upstream source. So, I just follow the line continuation
or RFC822 when filling in the copyright info.
Isn't that right?
> Why do you copy config.sub/guess in clean rather than in configure?
Because it came with old example debhelper file, and I forgot
to change it as done in my other packages. :P
OK. Thanks for pointing out. I'll change it.
> CFLAGS doesn't seem to be passed to configure?
It should. I'll change that.
> Please rewrite the descriptions considering the audience for each of
> them. libthai0/libthai-data will always be automatically installed,
> libthai-dev will sometimes be automatically installed (build-dep) and
> libthai-doc should be only installed by humans. libthai0/-data could
> have a one-line description, the amount of info in the -dev and -doc
> descriptions should reflect who will be looking for them.
I find this guideline for library description good, although
I don't see an example of such package yet.
I'll try to follow it.
> Tip: $(MAKE) -C foo works too
Oh, thanks I'd rather make myself used to it first, before
actually changing the code that I have to maintain in the
long run.
Thanks for all your comments.
Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
Reply to: