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

Packaging C-Library



Hi everybody, 

we've developed a lightweight mime library in C which attemps to be a general library for 
parsing and creating mime email messages and is designed to provide an easy to use and easy
to integrate interface for developers. I am also one of the upstream authors want to take care
about the package. 


http://www.libcmime.org


The library has a few dependencies:
* cmake >= 2.6 (http://www.cmake.org/)
* Flex >= 2.5.33 (http://flex.sourceforge.net/)
* Bison >= 1.8 (http://www.gnu.org/software/bison/)

I've also tried to create a debian package. Lintian gives me the following messages:

N: Processing binary package libcmime (version 0.1.9-1, arch amd64) ...
W: libcmime: package-name-doesnt-match-sonames libcmime0.1
N: 
N:    The package name of a library package should usually reflect the soname
N:    of the included library. The package name can determined from the
N:    library file name with the following code snippet:
N:    
N:     $ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | \
N:         sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/\L&/'
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: binaries, Type: binary, udeb




X: libcmime: shlib-calls-exit usr/lib/libcmime.so.0.1.9
N: 
N:    The listed shared library calls the C library exit() or _exit()
N:    functions.
N:    
N:    In the case of an error, the library should instead return an
N:    appropriate error code to the calling program which can then determine
N:    how to handle the error, including performing any required clean-up.
N:    
N:    In most cases, removing the call should be discussed with upstream,
N:    particularly as it may produce an ABI change.
N:    
N:    Severity: wishlist, Certainty: possible
N:    
N:    Check: shared-libs, Type: binary, udeb
N:    
N:    This tag is marked experimental, which means that the code that
N:    generates it is not as well-tested as the rest of Lintian and might
N:    still give surprising results. Feel free to ignore experimental tags
N:    that do not seem to make sense, though of course bug reports are always
N:    welcome.




W: libcmime: non-dev-pkg-with-shlib-symlink usr/lib/libcmime.so.0.1.9 usr/lib/libcmime.so
N: 
N:    Although this package is not a "-dev" package, it installs a
N:    "libsomething.so" symbolic link referencing the corresponding shared
N:    library. When the link doesn't include the version number, it is used by
N:    the linker when other programs are built against this shared library.
N:    
N:    Shared libraries are supposed to place such symbolic links in their
N:    respective "-dev" packages, so it is a bug to include it with the main
N:    library package.
N:    
N:    However, if this is a small package which includes the runtime and the
N:    development libraries, this is not a bug. In the latter case, please
N:    override this warning.
N:    
N:    Refer to Debian Policy Manual section 8.4 (Development files) for
N:    details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: shared-libs, Type: binary, udeb



As this is my first debian debian package which will provide a c library I ask for some suggestions
on how to clean these things. 

* The package is a small package. Should it, as it provides a shared lib, be broken up into to seperate
packages? Should it be libcmime-dev or just libcmime. Currently it's named just "libcmime".

* License is not up to date yet in debian/copyright - we switched to MIT 


I've uploaded a version to mentors:

http://mentors.debian.net/package/libcmime

The respective dsc file can be found at:
http://mentors.debian.net/debian/pool/main/libc/libcmime/libcmime_0.1.9-1.dsc

If you do not yet have a sponsor for your package you may want to go to
http://mentors.debian.net/sponsors/rfs-howto/libcmime

Any help for getting this package clear is appreciated.

Thank you,
Werner Detter


Reply to: