Re: Sharing data between maintainer scripts and debian/rules
Neil Williams <codehelp@debian.org> writes:
> 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 maintainer scripts aren't (usualy) build so you can't pass anything
from the build environment into them. If you do need/want to do this you
need to "build" those script in some form or another. For example I have
the following in a few cases (from memory):
debian/%: debian/%.in
sed 's/@VERSION@/$(VERSION)/g' < $+ > $@
binary-arch: debian/foo.postinst debian/foo.prerm
clean:
rm -f debian/foo.postinst debian/foo.prerm
Don't use a conffile for this. The file would only confuse users, tempt
them to edit the file and then what would your programm and maintainer
scripts do? That only invites chaos.
> 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.
Alternatively to the above, where every maintainer script has to be
build, you could add a single common file and source that in all
maintainer scripts. This would involve querying dpkg for the location of
maintainer scripts so it would add some overhead at install time.
> 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.
Maybe debhelper could add support for this, doing the sed for you when
it installs the maintainer scripts and replaces its own #DEBHELPER#. But
afaik there is nothing existing of that sort.
As for typos the sed commands are quite trivial and never change. So you
just write them and carefully check the result once. So I don't buy that
fear.
> 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.
For that there are provisions:
man 1 dpkg
DPKG_MAINTSCRIPT_PACKAGE
Defined by dpkg on the maintainer script environment to
the package name being handled.
DPKG_MAINTSCRIPT_ARCH
Defined by dpkg on the maintainer script environment to
the architecture the package got built for.
DPKG_MAINTSCRIPT_NAME
Defined by dpkg on the maintainer script environment to
the name of the script running (preinst, postinst, prerm,
postrm).
> 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.
MfG
Goswin
Reply to: