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

Re: Problem with a debian package (lib or not lib ?)



lördagen den 25 januari 2003 15.50 skrev Fabien Ventro:
> Hi,
>
> I have a few problem with one debian package. It isn't currently in
> debian, but the author a the package provied a debian directory. The
> package is kbiff (kbiff.sf.net) I managed to build the package, but I
> have the following errors :

Someone has been running deb-make on that program, but never fixed up the 
"example" files generated.  In my opinion that program does not make a 
particularly good debianisation for KDE programs, since you need to do quite 
a lot of hand editing.

> Now running lintian...

You can always run lintian with the -i option to get longer descriptions. 

> W: kbiff source: dh-make-template-in-source debian/prerm.ex
> W: kbiff source: dh-make-template-in-source debian/preinst.ex
> W: kbiff source: dh-make-template-in-source debian/postrm.ex
> W: kbiff source: dh-make-template-in-source debian/postinst.ex
> W: kbiff source: dh-make-template-in-source debian/menu.ex

Just remove all those files. Except for maybe menu.ex, which you can edit and 
remove the ".ex" from.

> W: kbiff source: out-of-date-standards-version 3.5.2

You have to read the new standard and upgrade with whatever is needed. 
That package is debianised with an old template from deb-make

> E: kbiff source: debian-files-list-in-source

I have no idea what that is.

> E: kbiff: no-shlibs-control-file usr/lib/kbiff.so
> E: kbiff: postinst-must-call-ldconfig usr/lib/kbiff.so
> W: kbiff: postrm-should-call-ldconfig usr/lib/kbiff.so
> E: kbiff: unparsable-menu-item /usr/lib/menu/kbiff:6
> E: kbiff: package-has-a-duplicate-relation xlibs (>> 4.1.0), xlibs (>>
> 4.2.0)

All this refers to shlibs. The easiest to get it right is to do
	dh_makeshlibs -V
.... and later
	dh_dhlibdeps -ldebian/kbiff/usr/lib
... but the exact argument for the latter depends on other things in the 
"rules" file.


 Finished running lintian.

> For the .ex file, I could remove them, but for the lib, I don't
> understand ! This package will not provide a library, only an app !For
> xlibs, I don't understand, too !

For KDE packages there should be no Build-Depends:  on xlibs in the 
debian/control file. xlibs is automatically included in the Depends if you 
Build-Depend on kdelibs4-dev, which in turn depends on libqt, which in turn 
depends on all kind of other stuff. 

For the Build-depends you have to be careful to depend on the correct version 
of automake. The way to figure out that is to do "head Makefile.in", and the 
version is in one of the top lines. Then you have to depend on that version 
of automake, and furthermore use that version for configure in the following 
fashion:

	AUTOMAKE=automake-1.5  ./configure $(configkde)

configkde contains the strings that KDE needs. They are setup up by 
admin/debianrules, a kind of help file that give strings that KDE need. 
Unfortunately it now does not give much more than configkde any more. I have 
my own version that does much more useful stuff. Stuff that you otherwise 
have to include in every debian/rules file.

Karolina



Reply to: