[debhelper-devel] Bug#734531: emacsen-common: handling of add-on packages still broken in some cases

[Agustin Martin]

2014/1/21 Agustin Martin <agmartin at debian.org>:
> 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
>> dependencies.
>>
>> 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.

Regards,

-- 
Agustin