[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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:

  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

  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).


  Please include the years of copyright holding, and also the GPL
  boilerplate *as found in the upstream source files*.

  Please consider moving DH_COMPAT=4 to ./debian/compat; see the
  rational at

  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..

  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:

  Could you install a static archive, also?

I'm sorry, but I can't sponsor your package, yet..

Clear skies,

Reply to: