[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Sharing data between maintainer scripts and debian/rules

We've a few native packages which handle data in package-specific
directories under /var/lib/. It would be convenient to specify the name
of this directory in debian/rules as a -D define to the compiler
(because it's native) and then pass that into the relevant maintainer
scripts, postinst and postrm. (We could use a prerm if appropriate.)

So rather than copying the directory name in various places in the
debian/ directory, I was wondering if there's a simple way to feed a
variable into the maintainer scripts from debian/rules (which in turn
could set the variable according to DEB_BUILD_OPTIONS and
dpkg-architecture query results). We could use a file in /etc/ but that
seems to just move the problem elsewhere and we could use a hidden
debconf value but that just adds complexity to the postinst itself.

The implementation is embedded, so unnecessary clock cycles (retrieval
from debconf) need to be avoided and the chances of a config file being
edited are slim (i.e. only during development) - there is no user login
and no user access. There is no python interpreter on-device and the
perl-modules package is not installed, so only the base perl interpreter
is present. Retrieving this variable on-device is therefore less than
appealing, the value needs to be in the postinst script that actually
ends up in the binary package.

Other than using sed and awk during the build on a package-specific
basis with all the potential for typos, is there a wider use case for
dissemination of variables from debian/rules into maintainer scripts? I
guess it's an extension of the #DEBHELPER# mechanism, which being on
the build system means that a lot more tools would be available.

Any mechanism would have to allow the old value to be identified upon a
change to the directory, so that the old data gets cleaned out
properly. i.e. when changed, the maintainer scripts end up handling two
locations, cleaning the old, populating the new.

There's also the possibility that the process needs to be
architecture-sensitive, i.e. the armel postinst might need to behave
differently from i386 because the armel device can do things which you
don't want a desktop to do (like suspend automatically). This is
relatively simple to do with some conditionals in debian/rules.

There remains the option of doing this all in the compiled code but I'm
interested in seeing if this is something other people need to do as


Neil Williams

Attachment: pgp0hZ7O1Mg_6.pgp
Description: PGP signature

Reply to: