Re: emacsen-common: handling of add-on packages still broken in some cases
2014/1/21 Agustin Martin <email@example.com>:
> On Sun, Jan 19, 2014 at 02:43:34PM -0600, Rob Browning wrote:
>> [summary for debhelper/dh_installemacsen: there may be additional
>> changes to policy soon.]
>> So I just realized that while I improved things a bit in 2.0.6/7, there
>> are still some broken cases. In particular I believe that
>> dpkg --purge emacsen-common
>> can cause trouble because emacsen-common will "rm -rf
>> /var/lib/emacsen-common". That leaves all the add-on packages
>> installed, but missing their
>> /var/lib/emacsen-common/state/package/installed/ files.
>> Then if/when emacsen-common is reinstalled, say indirectly via
>> apt-get install emacs24
>> none of the already installed add-on packages will be processed because
>> their state files are missing, and won't be recreated until the next
>> time they're upgraded or reinstalled.
> Can emacsen-common postinst be instructed to recreate all them when
> installed for the first time? List of add-ons can be extracted from
> "/usr/lib/emacsen-common/packages/install", just need to pass a flag file
> from preinst in case the emacsen-common dirs are not present. This flag file
> is checked from postinst, action is taken after it and removed if success.
>> All of these recent issues (and contemplating the fixes/workarounds)
>> make me suspect that it may have been unwise to try to make it possible
>> for add-on packages to have *no* emacs-infrastructure related
>> I'm not certain yet, but I believe that requiring add-on packages to
>> depend on emacsen-common (>> 2.0...) may make it much easier (and even
>> possible?) to handle the install/removal process correctly.
>> Currently, emacsen-common is only about 140k, and I don't expect it to
>> get much larger in the foreseeable future, so it doesn't seem like a
>> significant burden in exchange for what I think might be a much simpler,
>> and more obviously correct system.
>> As one example, the added dependency would allow us to remove the bit
>> just added to policy that required add-on packages to manually handle
>> their installed/state file.
> If possible, I'd greatly prefer things done without adding the explicit
> dependency, even if it is not big and does not pull other things. I'd leave
> the dependency only as last choice.
Already sent in private mail to add-on maintainers, adding here just
to have this recorded.
Not fully tested, but I think that, with some emacs flavour already installed
# dpkg --purge emacsen-common
# apt-get install emacsen-common
may result in missing byte-compilation for emacsen add-ons, neither
with the emacsen-common dependency nor with with my proposal.