Re: RFS: failmalloc - Memory allocation failure crash-test tool (2nd try)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-01-04 16:40, Alessandro Ghedini wrote:
> On Tue, Jan 04, 2011 at 02:21:16PM +0100, Niels Thykier wrote:
>> I thinking that devel might be a better section than utils. Particularly
>> the devel section covers "Development utilities" according to [1].
>
> Agreed.
>
>> 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.
>
> autotools-dev is needed, since it updates the config.{guess,sub} files
> during build (otherwise lintian would complain with the error
> ancient-autotools-helper-file).
>
Not quite correct. Lintian allows you to B-D on autotools-dev (among
others) to suppress this warning. Adding it to B-D makes lintian skip
the check entirely (yupe, I did look it up in the lintain source[1]). As
I recall you can do this with a B-D dh-autoreconf plus
%:
dh $@ --with autoreconf
in d/rules.
Though lintian will not suppress the warning in this case (see #592358).
In this case, just override the tag or even leave it there; I /suspect/
this will be fixed in lintian in one of the next versions.
> debhelper 7.0.50~ is indeed not needed.
>
>> 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.
>
> I was just following what upstream says ("This software generates a shared
> library which can be loaded by LD_PRELOAD or linked at compilation time.").
> The helper script was written mostly by me for this package, so probably
> others that have used the library before may want to not use it (so that
> there is no need to install its package). The same applies for the library's
> direct linkage: if someone prefers to use it that way (and it is supported
> upstream), who am I to judge? :)
>
True, but if they want to directly link against it they can still do it
by passing -L/usr/lib/libfailmalloc -lfailmalloc, so you are not
preventing it (just making it slightly less trivial).
As for linking against it and not needing failmalloc (binary package);
I think you would, since the unversioned symlink is shipped in
failmalloc (alternatively there is no reason to ship the unversioned
symlink in the failmalloc binary package).
> Anyway, I updated the package (both on mentors.debian.net and on git) with
> the other changes you suggested. Thank you for the help.
>
> Cheers
>
Anyhow, I am on my way out the door. :)
~Niels
[1] checks/cruft lines: 122 + 333 (plus 136 and 291)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNI0t5AAoJEAVLu599gGRCawMP/0CHzw5ZDouR5XX7vheFvbbM
ZkUFy72cOGOoNqUFHuh6EAu3z3KNsJ8geNh9bz2sb2uPfUIo7vU04UxYFE+RE6p0
0bsWXBCS7ikEqr6CqmgPcTclHcIoK5KtT0UJ5410yNb79tejndMvtiWh/Nb1iULz
7uGzYu209stulUPve5pB1NLXzR320tIsFkpPDwIN/SYIY/HBUB4qW9ImL6xBJ3JX
xuih/9z8E+8lNtD8icr35pCJPj7/6Wxmh4d83a2gh+rLgalcYdhbT1ABz1OS3CE1
aW9e6uGN6ZlsmI16vvv+iJHiPjrS46zHxDTXSi9DkZRhSzncmw0nZ075nHEb64ZB
e9oOqK/9B2/eylX1Dsw3BByzdhye8QuyaXSG3dgJyFMDhU5cb5UgOk2tG4Kckt03
hbu43JGIEWOG65rUkvJ1dhpvT9md21KaIVip9cYy23TROcB/zohM3+JAA/NXjdRx
7eiOtJmbfqil1COjlEokwgEmTqBP40NF4JAK726f1SYe6+WpuR80cY59peA2yIfv
lL8+4CM2tZdKmn6h9Wxfb1iVd8SJDvlEE1VXV894NclhQVxkWXI13g3eBFOfpGNR
pXPaYCzFZ1qLjQiKTPMZ1MNr1Qf5Kdq3IDBOnnHQhOTmo1wd6r6cY/ngkXidUtYY
6KZo2FOMTncV0ummCcWs
=u/BX
-----END PGP SIGNATURE-----
Reply to: