On Tue, Jul 06, 2010 at 10:46:57PM -0500, Rob Browning wrote:
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
>
> > Rob Browning writes ("RFC: relaxation of debian-emacs-policy dependency
> > requirements"):
> >> After some investigation, it looks like we might be able to change
> >> policy to just require add-on packages to depend on emacsen-common,
> >> which is reasonably small, ~150k, and could probably become smaller if
> >> necessary.
> >
> > Why should a package which happens to also ship some elisp need to
> > depend on any Emacs package at all ? What will go wrong if the
> > package is installed without any Emacs ?
>
> If the package doesn't need to use any of the emacsen-common build
> infrastructure (doesn't need to byte-compile for each flavor, etc.),
> then it doesn't need to have any emacsen-related dependencies -- that's
> already in policy.
>
> For packages that do need to use the infrastructure, I believe the
> original intent was to make sure that an add-on package couldn't start
> using emacsen-common before it was fully configured. It may be possible
> to re-write emacsen-common to change that requirement, but I'm not
> certain offhand.
I think we should put that check into add-ons, not emacsen-common, so it
does not need rewrite. For the records that has been done in
dictionaries-common for years using the 'installed-flavours' trick (Yes, I
will change to something better as soon as needed) and no one complained
about bugs associated to it. Other more complex packages may not work, but
I expect most simple add-ons to work this way.
> If we do want to try to eliminate that requirement, there are a number
> of important constraints (which are also open for discussion):
>
> - Any time an add-on package is installed or upgraded, it should be
> automatically "built" (whatever that means, but it usually means
> byte-compilation) for every installed flavor of emacs.
That should already be done through
#PACKAGE#.prerm: /usr/lib/emacsen-common/emacs-package-remove #PACKAGE#
#PACKAGE#.postinst: /usr/lib/emacsen-common/emacs-package-install #PACKAGE#
for installed flavours, after checking emacsen-common status if needed
> - Any time a flavor of emacs is installed or upgraded, every
> *fully-installed*[1] add-on package should be automatically
> (re)built for that flavor of emacs in an order that respects any
> inter-add-on-package dependencies (i.e. say auctex "Depends:
> foo-el"). Currently this ordering is handled manually via tsort
> from the emacs-install script.
For this I see no easy way of doing things apart from using tsort, as you
currently do from the emacs-install script. Of course, with the tsort stuff
this should work.
$flavour.prerm: /usr/lib/emacsen-common/emacs-remove $flavour
$flavour.postinst: /usr/lib/emacsen-common/emacs-install $flavour
However, I'd be happy if this can be improved.
> - Every time an emacs flavor is removed, all of the add-ons should
> clean themselves up with respect to that flavor.
>
> - Every time an add-on package is removed, it should clean itself up
> with respect to every installed flavor of emacs.
For single flavour or add-on package removal appropriate above remove
line should work. For combined flavour or add-on package removal first prerm
run will do the removal, the other will not find anything left to remove for
the add-on.
> - If some collection of add-on packages and some collection of flavors
> of emacs are installed in the same dpkg run, the "right thing"
> should happen, no matter the order in which dpkg decides to handle them.
If emacs flavour is processed first, tsort code in emacs-install script will
take care of things. Otherwise normal dependency mechanism should be
honoured by dpkg. If emacs flavour postinst goes in the middle should do the
work left in a way controlled by tsort while previous stuff was controlled by
dpkg dependencies.
> - Ideally, there should be no redundant add-on package builds, but
> right now, there may be. Imagine "apt-get install auctex emacs23"
> At the moment, I believe auctex will be built twice.
For the records, dictionaries-common uses flags like
/usr/share/$flavour/site-lisp/dictionaries-common/done
to signal that things are already built and do not need further rebuild.
It is removed from prerm code.
> - Add-on packages should not be built before all of their package
> dependencies are installed[1], including non-emacs-related deps. This
> is currently a problem -- imagine an "apt-get install emacs21 auctex"
> where auctex depends on gs and gs (or a gs provider) isn't installed.
> If auctex doesn't depend on emacs21, and dpkg installs emacs21 first,
> such that emacs21's postinst goes first, that postinst may call
> auctex's emasen-common install script to build it when gs isn't
> available. See
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370672). The
This is a real problem that current system cannot address
> "Depends: foo-el" mentioned above provides a similar problem.
even with a depends on gs. I looked at auctex code at
/usr/share/emacs/site-lisp-auctex very quickly and did not see if there is a
reason to hardcode path that way or something like (executable-find "gs")
or similar for other w32/not-w32 names could do things dynamically on emacs
run instead of when byte-compiling.
> I brought up this RFC because lately I've been trying to determine how
> we might be able to improve the current situation, and I've been
> learning about triggers to see if they might help. So far, I just know
> that triggers can't help with add-on removal since they fire after the
> add-on package has been removed.
Rob, thanks a lot for doing all this work and bring this RFC.
[PS: I read debian-emacsen]
--
Agustin
--
To UNSUBSCRIBE, email to debian-emacsen-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100707133548.ga2...@agmartin.aq.upm.es
