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 well. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpOQAbocDcqr.pgp
Description: PGP signature