Agustin Martin <agustin6mar...@gmail.com> writes: > Did not test in depth, but I think the add-on state files state files > could be recreated from /usr/lib/emacsen-common/packages/install in > case emacsen-common is installed for the first time (i.e., not > upgraded). Since emacs flavours depend on emacsen-common they should > byte compile things when configured.
I may be misunderstanding, but if not, I think the problem there is simultaneous installs (which are our primary complication in general), i.e. most of the complexity we have comes from the fact that we're operating outside dpkg's dependency system (to avoid add-on deps), and so we have no ordering guarantees. That's why I added the state/package/installed infrastructure, but I'm beginning to think that this approach may just be insufficient. The original idea was that the state files would allow add-ons to signal that they're "ready to go" with respect to emacsen-common install/remove calls. For example, consider the case where no emacsen-related packages are installed and someone runs this: apt-get install emacs24 add-on-1 Because there are no relevant dpkg deps, the packages' maintainer scripts can fire in any relative order, and if emacs24's postinst fires before add-on-1's, it can know to skip installing add-on-1 because package/installed/add-on-1 doesn't exist. But emacs24 *will* create flavor/installed/emacs24, so that when add-on-1's postinst fires, its install script will be run for emacs24. Of course, something reasonable should also happen if the order is reversed. However, to demonstrate why I'm beginning to think the current approach may be unworkable, consider the case where no emacsen-related packages are installed and someone runs this: apt-get install emacs24 add-on-depending-on-add-on-1 add-on-1 What should happen if the postinsts fire in the order listed? When add-on-depending-on-add-on-1's postinst fires, add-on-1 isn't "installed", and so add-on-depending-on-add-on-1 should be skipped (though that may actually be broken right now), and then when add-on-1's postinst fires, it's not (currently) going to do anything about the other add-on because add-on-depending-on-add-on-1 isn't a dependency for add-on-1. I begin to suspect that up to now, we may have just been fairly lucky, and that the current approach is may just be broken for any number of cases like this. And unfortunately, adding the emacsen-common dependency won't help. Another reason why I keep wondering about the possibility of using triggers is that even if we addressed some of the above issues, the current approach will still probably result in redundant installs from time to time. Even if you want to be conservative and expect to reinstall an add-on whenever it's upgraded, or any flavor is upgraded, consider the previous example, but assume that all of the packages are already installed (just being upgraded): apt-get install emacs24 add-on-depending-on-add-on-1 add-on-1 Currently, the emacs24 postinst will install both of the add-ons, and then each add-on will install itself, and add-on-depending-on-add-on-1 will also reinstall add-on-1 again. With a triggers-based approach you'd hope that we could coordinate better, and only run each install once. So, generally speaking, unless we come up with alternatives, I'm beginning to wonder if triggers may be our best option, assuming we can shoehorn all add-ons into accommodating the attendant restrictions (whatever they end up being). > If something like this does not work adding the dependency is the > lesser evil as long as emacsen-common NEVER tries to pull emacsen nor > anything that should not be present in a very minimal system. But I > still prefer a fix into emacsen-common itself if possible. Right -- if we go this way, I'd plan to keep emacsen-common very small, and as independent as possible. > Other interesting things were proposed in this thread like having > support for things like > > elfiles=foo.el bar.el autoload.el > . /usr/lib/emacsen-common/emacs-install-standard.sh > > but while highly desirable this is something different from the > original problem this thread is about. Agreed, and there are a number of ways we might manage something like that, which might or might not involve the code going directly into emacsen-common -- i.e. we might want a separate binary package that the relevant add-ons could depend on. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel
