Re: [RFS] skim - smart common input method platform for KDE
On Sat, Dec 03, 2005 at 04:09:22PM +0800, William J Beksi wrote:
> I am looking for someone to sponsor skim. My package is on Debian
> mentors (skim_1.4.3):
> http://mentors.debian.net/debian/pool/main/s/skim/
>
> It is lintian clean but has the following linda warnings listed below.
> Any comments would be greatly appreciated.
> W: libskim0; The library libscim is not in a shlibs file.
> The library shown above is not listed in a shlibs file. This means
> that packages that depend on this one won't get ${shlibs:Depends}
> correctly.
This is a serious bug; see also #339056. Since you provide libskim0
and libskim-dev, it is gives the impression that you intend to
provide public libraries for use by other programs.
The sole purpose of those binary packages is to provide a shared
library against which other programs may link. If that other program
is packaged for Debian, and you do not provide a shlibs file, then
that other program will not have a Depends: libskim0, and will thusly
be installable without libskim0, which is a serious bug in that
program..
You call dh_makeshlibs, but with -X argument, which I think prevents
creation of the necessary file.
Your other option is to not provide libraries, or to provide
libraries, but private ones, instead of public (I don't know if this
is what you want, though). You can link the executables against the
statically compiled (without -fPIC) libraries, or put the libraries in
/usr/lib/skim/, and use an LD_LIBRARY_PATH wrapper, or use rpath
(which I guess is accepted for nonpublic libraries). Or link by
filename (which I guess is a contentious practice) practice. As in:
gcc -o foo *.o /usr/lib/skim/libskim.so
Other comments:
./debian/control:
Section:
libs rather than utils, I think, if you are going to provide public
libs. Maybe set the scim binary package to section utils. AFAIK
binary packages inherit the section from their source package, by
default.
Build-Depends: libscim-dev
doesn't this mean that you have to bootstrap libscim-dev for all
architectures? That is a a showstopper IMHO. OTOH right now I
think your libscim-dev is Arch: all until you provide a static
library (see below).
./debian/copyright:
Please include the years of copyright holding, and also the GPL
boilerplate *as found in the upstream source files*.
./debian/rules:
Please consider moving DH_COMPAT=4 to ./debian/compat; see the
rational at
<http://lists.debian.org/debian-mentors/2005/11/msg00247.html>.
You might also consider using version 5 (and B-D: on bumped
debhelper version).
This is being really picky, and maybe I don't understand, but:
$(SCONS) -c && rm cache -fr
doesn't make sense to me; I'm guessing that scons -c creates
./cache? Why not $(SCONS) -c && rm cache? This includes the
additional assertion that ./cache exists. Assertive programming is
a Good Thing. (Is cache a directory? If so, then rm -r ./cache).
+# dh_install
Um, aren't you using the *.install files? THen you need to
uncomment this..
./debian/watch
Please consider using the qa.debian.org sourceforge redirect, to
increase the liklyhood that watchfiles actually work for more than
one person..
Format is:
# http://sf.net/#PACKAGE#/#PACKAGE#-(.*)\.tar\.gz
For more info:
/usr/share/debhelper/dh_make/debians/watch.ex
/usr/bin/uscan
http://qa.debian.org/watch/sf.php
./debian/libskim-dev.install
Could you install a static archive, also?
I'm sorry, but I can't sponsor your package, yet..
--
Clear skies,
Justin
Reply to: