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

Re: emacsen-common: handling of add-on packages still broken in some cases

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.



Reply to: