Re: RFS: hexec
Hi,
thanks for your feedback.
On Monday 01 December 2008 16:04:33 Alexander Block wrote:
Hi,
Hm, interesting approach. Package looks good to me, except that it builds one
binary package, not three, which is fine. Adding a watch file would be good
idea too, regardless you are both upstream and debian maintainer of that
package, because in that case your users (Debian External Health Status -
DEHS included) would be able to catch your debian packaging lagging your
upstream releases, if any ;-)
I will add the watch file today or tomorrow.
I seem to be confused with the binary listing in the RFS...
As I understand it now, I have to list the same packages as listed in
the debian/control? I thought this had to be a list of all executables
and *.so files ;-)
These are leftovers, right ? I see no good reason to split two separate
runtime library packages if your `application' package (built from the same
source package) needs them both to operate as well. Or these are just long
forgotten bits from a library/dev split attempt ? If you intend to distibute
a) separate runtime `library' packages (the shared library) and b) separate
buildtime `development' packages (headers and static library) then it might
make any sense to leave your users some options to choose which of these they
would need and not bother with the rest, i.e. they might want to build depend
on libhook-dev, but not on libfoo-dev (produced from the same source
package). That gains you almost nothing, but anyway.
Nope, they are not leftovers. Especially libhexec-hook.so is required
for the exec hooking, which is based on LD_PRELOAD and always
needs a shared library. I used libhexec-common.so to share code
between the LD_PRELOAD .so and the command line tool (hexec).
I could possibly remove the need of libhexec-common.so and change
it to be a static library, do you think this is the better solution?
Btw, there will never be a need for a -dev package, as the libraries
are really only internally useful.
I think I should maybe create a new package with the suggested
modifications (I also got some feedback on IRC and private messages),
so the current package should not be uploaded.
Reply to: