Agustin Martin <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
