Do the right thing (TM)

Francesco P. Lovergine frankie at debian.org
Thu Mar 17 11:30:22 UTC 2011


I just realized all of you did not read the latest README.Debian for
proftpd-dev. The result is that all modules currently loaded on the
git repo are basically doing the wrong thing. Unfortunately I had
a momentary lapse of reason about the -dnsl module and uploaded
as it is. Specifically using @VERSION or other similar tricks
is basically wrong and could result in wrong upgrading roadmaps
(i.e. module installed not built for the proftpd core package).

Note that basically proftpd DOES NOT ensure against ABI changes
from one release to another and we have to force a new ABI
(with required binNMU calls for d-release folks) at each new
upstream release.


ProFTPD third parties module and packages development
-----------------------------------------------------

Upstream provides `prxs' as a useful tool to build your own proftpd DSO modules. 
The resulting shared library can be loaded in the /usr/lib/proftpd directory to
allow proftpd finding the additional module.
This could be done with a command like

    prxs -c -i -d mod_foo.c

The resulting module mod_foo.so is strictly binary-dependent on the specific
version of proftpd you used to build it by prxs. If you prefer creating
a deb source package Debian proftpd-dev package provides

    /usr/share/proftpd/proftpd-substvars

which can be used to introduce a dependency on ${proftpd:Depends} in
your debian/control for foo binary package. You have to add its contents
to a debian/<foo>.substvars or debian/substvars with a command like

    cat /usr/share/proftpd/proftpd-substvars >>debian/<foo>.substvars

just before calling dh_gencontrol or dpkg-gencontrol.

----

Incidentally I need to fix a couple of typo both in the substvars file
and in the documentation about that.



-- 
Francesco P. Lovergine



More information about the Pkg-proftpd-maintainers mailing list