[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: relaxation of debian-emacs-policy dependency requirements

On Tue, Jul 06, 2010 at 10:46:57PM -0500, Rob Browning wrote:
> Ian Jackson <ijackson@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


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]


Reply to: