Re: RFS: failmalloc - Memory allocation failure crash-test tool (2nd try)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-01-04 12:31, Alessandro Ghedini wrote:
> Dear mentors,
>
> I am looking for a sponsor for my package "failmalloc".
>
Hey
Thanks for your interest in Debian. This is indeed an interesting
library. :)
> * Package name : failmalloc
> Version : 1.0-1
> Upstream Author : Yoshinori K. Okuji <okuji@enbug.org>
> * URL : http://www.nongnu.org/failmalloc
> * License : LGPL-2+
> Section : utils
>
I thinking that devel might be a better section than utils. Particularly
the devel section covers "Development utilities" according to [1].
> It builds these binary packages:
> failmalloc - Memory allocation failure crash-test tool
> libfailmalloc0 - Memory allocation failure crash-test tool (library)
>
> The package appears to be lintian clean.
>
> The upload would fix these bugs: 462792 (ITP)
>
> [...]
>
> I would be glad if someone uploaded this package for me.
>
> Kind regards
> Alessandro Ghedini
>
>
Any particular reason for Build-Depending on autotools-dev? It does not
appear to be required for the actual build? Likewise you do not need
debhelper >= 7.0.50~ since you do not have any override targets.
Regarding the library <-> application split; I am not entirely sure what
is best. The best "similar" case I can think of would probably be
fakeroot, which installs its helper library in /usr/lib/libfakeroot/ and
then does without the lib-package. I also noticed that libeatmydata does
the same.
Admittedly it is far less likely to make sense to compile your
application directly against one of those libraries. Nevertheless I
doubt a lot of developers would link the production releases against
this library either.
~Niels
[1] http://packages.debian.org/unstable/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNIx7MAAoJEAVLu599gGRCw60P/iTIQOLRJGiQOvCagWbWF/yR
HulQz4vkHJa9cXyNtDuGriSEhwjsjkYBB6eMJCbfvVO/6cbdbSZT3dTg2hbbn/C9
Uzos5Tez4oM3bdgfe4WGgF2BkpCjcX7dMUCcuKEvF6FzuIMqOgB6A4W2ACulUXw3
iky+FsB3Cea3VVVMsSm/+z2Z+9YHcqzj0bLPDWAgEDpVEwWRiL+GgYqQBBL86NEC
2EdPfJtrYioJFtwiCSPyavciTgI5ZIdbrP+oNPDJWD4cew9z/sWkHdMxOkZhms0L
SKR3ar6ACKUxGkGkv8W0lWYgTJOhoHok9g3n1hIU+TF8P3CM+wOLGGgtNbitd3EL
5N1cXCwKNbCZOxxHjHRSYNISivPfAPaOaVKhXWtjQTWtPdU0tiN44Ai9T5FtUk2A
2WbTEB2rFETay/CnJsXARQ24oZuHo/TWE7tRbdHaLxjewXfnBoWaMoCaRQ6WYeeN
MPF4Id0T++0CvCjYzeDpc4sofCkluG/V6+UqS86JW9042GNs/quqFyzJ7iT1ZLyQ
8z9QCAXDpH1xl1Npl34/Q/umvNdLAYAo1LyyPXQzaMxJL8C9QlaLLP+1d3B/HCtz
nkXHwEuR+31KW2LoBolbf8PQ7SWbXUqHZRA8lyPI+9hbJ6KehpyuY+uI1R5BK7kD
F+XyjNiRgUfEMbSDXPK4
=oqJ/
-----END PGP SIGNATURE-----
Reply to: