Re: RFC: relaxation of debian-emacs-policy dependency requirements
Agustin Martin <agmartin@debian.org> writes:
> 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.
I'd be quite happy if we really can eliminate any need for add-on
packages to depend on emacsen-common. The main objection I have to the
use of installed-flavors is that it's an implementation detail (and one
I've been thinking about changing), but I'm fine with adding an
officially documented mechanism, one that we plan to support
indefinitely, presuming it ends up being reasonable.
As an example, and as I hinted, I've been wondering if we might be able
to resolve some of the remaining problems by maintaining some stamp
files from within emacsen-common, perhaps
/var/lib/emacsen-common/state/package/installed/FOO
and
/var/lib/emacsen-common/state/flavor/installed/FOO
[which would obviate installed-flavors]
(Though earlier for some reason, I thought that maintaining
.../installing/FOO instead (or in addition) might work better wrt
backward compatibility -- can't recall why ATM.)
If we did maintain such state files, then I think it'd be fine to
specify that add-on packages should test for the availability of
emacsen-common (and guard calls to emacsen-common tools) like this:
test -e /var/lib/emacsen-common/state/package/installed/emacsen-common
All the state files would be maintained by emacsen-common from the
emacs-install and emacs-package-install scripts, and we'd need to add a
requirement that emacs flavors and add-on packages call something like
"emacs-install --preinst ..." or "emacs-package-install --preinst ..."
from their respective preinst scripts.
So at this point, I'm trying to figure out if these state files will
make it possible for emacsen-common to know when it's OK to run a given
packages' install/remove scripts, and help eliminate duplicate runs.
> 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.
I think the state files might help here. The first prerm that fires
will call emacs-package-remove (or emacs-remove) which will call the
package's emacsen-common remove script, and then update the state
file(s). So when the second prerm calls emacs-package-remove (or
emacs-remove), the state file(s) will indicate that package should be
skipped.
>> - 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.
Right. I think I may just be proposing that we make something like this
part of policy, and automatic (internal to emacsen-common), for all
packages and flavors.
>> - 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
I think this proposal, or something like it might. If the emacs
postinst fires first, then the state files will tell emacsen-common to
ignore the add-on package. Later, when the add-on package's preinst
fires, it'll build.
> Rob, thanks a lot for doing all this work and bring this RFC.
Certainly. Thanks for the help.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: