FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-04-2011, 11:54 AM
Neil Williams
 
Default 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
well.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 11-05-2011, 07:33 PM
Frank Küster
 
Default Sharing data between maintainer scripts and debian/rules

Neil Williams <codehelp@debian.org> wrote:

> 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?

In tex-common and texlive-{base,extra,lang,doc}, we use eperl.
debian/rules has a section like this:

# create maintainer scripts etc.
EPERL_FILES := debian/common.functions debian/postinst debian/postrm debian/config debian/preinst
eperl_sourcefiles=debian/variables debian/COPYRIGHT.scripts debian/postinst.functions
debian/common.variables debian/common.functions debian/postrm.functions

# Eperl is simply great: thanks, Davide!
% :: %.in $(eperl_sourcefiles)
eperl -k -P -o $@ $<

Then you edit postinst.in, postrm.in and they eperl'ishly include
common.functions, common.variables

You can even have rules.in like this.

The original idea is from Davide Salvetti in his auctex package, but I
wouldn't recommend this any more - the packaging may be "aesthetic", but
it is overcomplicated. In particular, newer upstream versions probably
don't need much more than ./configure; make; make install.

Regards, Frank
--
Frank Küster
Sprecher B90/Grüne OV Miltenberg und Umgebung
VCD Miltenberg, ADFC Aschaffenburg-Miltenberg
Debian Developer (TeXLive)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874nyi5mx5.fsf@alhambra.kuesterei.ch">http://lists.debian.org/874nyi5mx5.fsf@alhambra.kuesterei.ch
 
Old 11-15-2011, 05:51 PM
Goswin von Brederlow
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fwhpqkwm.fsf@frosties.localnet">http://lists.debian.org/87fwhpqkwm.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 12:18 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org