Re: search-citeseer_0.1-1_i386.changes REJECTED
Henning Makholm wrote:
Scripsit Agustin Martin Domingo <firstname.lastname@example.org>
Last time I read about that, if is byte compiled it should depend on
virtual package 'emacsen' (provided by all emacs flavours), since
otherwise emacs-package-install failed if no emacsen was installed.
If that is true, shouldn't it be counsidered a bug in emacsen-common?
I could finally take a look at this. The failure appears only when the
package providing the extra lisp file (name it 'the_package' for
simplicity) tries to run emacs-package-install before emacsen-common is
fully configured. This is fixed with a dependency on emacsen-common in
Sometimes this might not be desirable, e.g. when 'the_package' is of
priority 'standard', since it would pull a 'optional' priority package
like emacsen-common. This could have been the reason that made Peter
split his package. What I mean is that if the emacsen-common configure
check is done in the postinst (checking if
/var/lib/emacsen-common/installed-flavors is present), even that
dependency could perhaps be avoided. As a matter of fact the above
snippet is the debhelper snippet slightly modified for that check.
You can try a workaround like this
if [ "$1" = "configure" -a -x \
This wouldn't work - if the package was installed before
emacsen-common, its files would never be byte-compiled even
if emacs was later added to the system.
I am not that sure, unless I am missing something, the files will be
byte-compiled as soon as an emacs flavour (name it 'emacsen' for
simplicity) is installed, since then all
/usr/lib/emacsen-common/packages/install/* scripts will be re-run
(appropiately sorted) for the installed flavour.
(And there's no telling
whether things would break horribly if emacsen-common happened
to be unpacked but not yet configured when the postinst script
In that case nothing would happen until an emacsen is installed, where
all remaining lisp files will be byte compiled for its flavour.
I think there are basically two possibilities, once 'the_package',
emacsen-common and an emacsen are unpacked:
a) If emacsen-common & emacsen are configured first, the lisp files for
that package will be byte-compiled twice, once by the emacsen postinst
and once again by the package postinst
b) If the_package is configured first, nothing will be byte compiled
from its postinst, but everything will be byte compiled at emacsen
postinst (since emacsen depend on emacsen-common, emacsen-common is
already configured when emacsen postinst is run). Well, this looks even
good, seems that we are saving one byte-compile run for 'the_package'.
All this looks too nice, am I missing something?