On Fri, 2012-11-30 at 11:24:48 -0800, Don Armstrong wrote: > On Fri, 30 Nov 2012, Guillem Jover wrote: > > In any case, regardless of this, semantics-wise I don't think it > > makes much sense to have both of them present. I'll be fixing the > > deb-triggers(5) man page to clarify this. > > I'm not sure I follow you here; allowing for both of them means that > the triggering package can define whether the triggered feature is > crucial, or not essential to its function. Doing it the other way > around means that only the triggered package can define whether the > feature is crucial or not essential.
This is already supported, and now having rechecked the patch in more detail and having paid attention :), you are already making use of it by calling dpkg-trigger with --no-await, which activates a trigger w/o marking the activating package as needing to await processing. You have to think about the interest* directives as default behaviour, so if the directive is synchronous, you can still activate it asynchronously (with dpkg-trigger --noawait). If the interested package marks it as noawait then it means it's really never needed for triggering packages to await processing; an example of this latter case could be man page cache regeneration. Those default directives are also needed so that implicit triggering, like the ones activated via path changes by dpkg itself during unpack/remove/etc, can behave in a way or another, but there needs to be only one, two directives does not make sense, which one would apply then? So, it really looks like these packages were behaving like if they only had «interest foo» (due to the stomping I mentioned before) and the trigger was asynchronous anyway due to the dpkg-trigger call, so you don't really need to use interest-noawait support nor the dpkg Pre-Depends anyway, and the possible upgrade issues just disappear. > > It'd probably be a good idea to discuss and try to come up with a > > way to notify dpkg and/or frontends, that they might need to restart > > themselves because a package requires one of its new features, so > > that some of those can be deployed w/o having to wait a full release > > cycle. I've added this to my TODO list for after wheezy. > > That should actually be pretty easy for the frontends just to handle. > If a package pre-depends on dpkg or some other essential package > required for the upgrade, it should do those upgrades first, then do > the rest of them. dpkg doesn't really need to do anything. That's one of the solutions that had crossed my mind too, but it might be too restritive in how frontends might need to prepare transactions, so it might be too heavy handed. The only problem here is just dpkg (perhaps the frontends itself too, but nothing else really), as the running process that gets out of sync with its own database, but asking frontends to hardcode a special case for the dpkg package might not be liked, and instead a metadata-based solution might be preferred, that's why I mentioned that this would need discussion. :) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
