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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
