Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > According to > https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html the > dependencies will have previously been configured and not removed. > I'm not sure what state you found they were in but I would bet against > there being a dpkg bug in this area.
I'd have to try to recall the exact details, but it didn't sound like there was any bug. The current emacs policy had just incorrectly assumed (among a number of related incorrect assumptions) that if an add-on depended on emacsen-common, then emacsen-common would normally be fully configured during the add-on's prerm, and that's just not true, as we discovered when I read that page fairly carefully a while back (after the related bugs were reported). > Can't you look in the filesystem? I would do this by having E's > postinst look in /usr for what things to compile. It doesn't need to > know the dpkg status. In the the framework of the original policy it did, because we couldn't/didn't assume what an add-on might need to do to become "ready" in its postinst configure, i.e. the policy requires that an add-on has to be past its successful postinst configure to be "ready" for anything else to depend on, including compilations. If we're willing/able to commit to the restriction that just having "add-on files in place" is always sufficient, then that may well simplify things. I'm not yet certain that's true (that no add-ons need to do "more" in their configure before another add-on can "use" them), but it may be. > I don't think this is the right approach. Instead, recompile > everything that is physically present. This ought to work right for > anything that's not "half-installed", and in that case it can (and > should be) fixed by reinstalling the half-installed package's .deb. > In the meantime E's trigger run can fail. (But "half-installed" is > very rare.) For this to work, I suppose we'll have to be sure that (as mentioned above) "files have all been unpacked" is sufficient for all add-ons. > The trigger system arranges that the hook you provide will run *again* > if it didn't run last. Ie, it must tolerate being run not-last, but > if anything *else* happens to trigger it after that, it will run > again. > > I think this is the only reasonably plausible semantics (and it's > sufficient for your purposes). Right, I think that was one of the expectations in the proposal at the end of the previous message. > You want to be very careful with any separate state you maintain. > That can make things significantly more complicated. By recording > state separately, you introduce the possibility of bugs where the > separately-recorded information is wrong (ie, doesn't reflect the real > state of the system). Of course. We'd only want that complexity if we had to have it (e.g. if "merely being unpacked" isn't sufficient). In any case, I think you may have addressed the key question -- and so we may actually be able to use triggers, and then perhaps whether or not we neeed custom state can be a separable question, to be determined by whether "just being unpacked" is enough. > (This doesn't prevent you from putting the code for the compilation > framework into a common package; the flavour's postinst can call it.) Sure, again, as long as the common package doesn't need to do anything in its postinst configure in order to be "ready". Otherwise, that's what we've been doing, and is the precipitant of this whole reevaluation. Installations were failing because add-ons that depended on emacsen-common were crashing when it wasn't ready (configured) when they tried to use it in their maintscripts (outside postinst configure). e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040690#115 > The trigger system works better when central packages are interested > and leaf packages do the triggering. This proposal inverts that. OK, I'll rethink the arrangements with that in mind. And just to double-check. It sounds like "postinst trigger" invocations can expect their deps to be configured. Once triggered, is there any ordering with respect to the "postinst trigger" invocations for multiple interested/awaiting packages, or is that "undefined"? Thanks much -- 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
