Andreas Barth writes: > Ian Jackson ([EMAIL PROTECTED]) [070410 20:39]: > > A file trigger is guaranteed to be activated before the file in > > question is modified by dpkg; on the other hand, a file trigger might > > be activated even though no file was actually modified. > > Why should it be activated *before* the file is modified? For the cases > where I think about it might be a good thing if it is activated after > the fact (so that e.g. the list of available fonts can be changed).
Activation has to precede modification because otherwise the system goes through a forbidden state: modified but not activiated. These should be avoided; dpkg is not supposed to ever leave the system in an horrid state even if it crashes unexpectedly. I'm not sure I understand your example. > Please also ignore anything after "#", so that one can write > interest foo # necessary for ... > interest bar # drop after release of Lenny OK. > > dpkg --configure --pending > > dpkg --triggers > > why not require --pending here as well? (just for "being the same") I think I should permit --pending but not require it. > I don't think it is a good idea to describe some package this way It does seem to be causing controversy. I've toned it down. > btw, what is the problem if dh_scrollkeeper does something like this: > if [ $1 -eq configure ]; then > if ! dpkg --assert-triggers ; then > # run update as it used to be > fi > fi What you really want to know is `is this trigger going to be run any time soon', that's difficult to know. In particular, you don't know whether dpkg is going to be upgraded to a triggers-supporting version, or whether a triggers-supporting dpkg is deferring new trigger processing according to the transitional arrangements. I'm working on the assumption that usually the consequences of lack of trigger processing in some corner upgrade cases are less bad than the consequences of excessive trigger processing or excessive fragility. > Alternatively, one could execute dpkg --compare-versions $(dpkg -l | cut > -f 1 -d ' ') -lt .., but I think that would be more crappy. (Or even > worse, use -d /var/lib/...) I would like a design that didn't need anything along any of these lines and I think I have one. > > These trigger activations will not be processed in the same dpkg run, > > to avoid unexpectedly processing triggers while attempting an > > unrelated operation. dpkg --configure --pending (and not other dpkg > > operations) will run the triggers, and the dpkg postinst will warn the > > user about the need to run it. > > Please supress the warnings in case there are no interessts registered. Of course. > > To use this correctly: > > * Update instructions and tools should arrange to run > > dpkg --configure --pending > > after the install; this will process the pending triggers. > > I don't think this is an acceptable approache for stable releases - we > need to consider something else for that. (And, BTW, dpkg --triggers > --pending should do the same IMHO.) Err, you don't think it's acceptable that stable releases upgrade tools should arrange to run --configure --pending ? Or do you mean that it wouldn't be acceptable to do this only via documentation (in which case I agree with you) ? > > * Declare an interest in the trigger. > > * Declare a versioned dependency on a triggers-supporting dpkg. > > * In the postinst, arrange for the new `trigger' invocation to run > > update-consumer. (The consumer package's postinst will alread > > run update-consumer during configuration, and this should be > > retained.) > > I think this makes upgrade cycles unnecessary complex. How about "change > the name of update-consomer, and put a transition script at the old > place which checks if it is run in an trigger-aware environment, and if > not, run the real update-consumer"? Do you think it's too difficult to ask that the package processing tools are updated early ? It seems to me to be an obvious requirement for upgrades. I don't think adding complexity in all of the consumer packages is the best way forward. It is IMO better in this case to add a dependency (which adds a not-unreasonable constraint to upgrades) than to add machinery to deal with both cases. > > The activation of a trigger does not record details of the activating > > event. For example, file triggers do not inform the package of the > > filename. In the future this might be added as an additional feature, > > but there are some problems with this. > > How about having the names print out by some "special" > dpkg-triggers-call (once this is implemented of course)? It might be possible but I definitely don't want to go there now. Re error handling: > > Alternatively, in some situations it may be more desirable to allow > > the interested package to be configured even though it can only > > provide partial service. In this case clear information will have to > > be given in appropriate places about the missing functionality, and a > > record should be made of the cause of the errors. However, this > > option is not normally recommended unless the coupling between the > > interested and triggering package is particularly loose. > > Wouldn't it be better to allow a package to "kick back" a dependend > package into config-failed? (So, if A triggers package B, and B notices > A did something *very* wrong, B can make A going to config-failed, and > configure itself successfully.) I think this would result in maintainers playing core wars on the users' systems (already rather a problem). Perhaps I should encourage the decoupled approach more. In practice in our current setup, leaving a package in a bad state is not really helpful to the user. None of the contemporary package management tools using libapt cope at all well. dselect (without `apt acquisition') is somewhat better although still not ideal and no-one but a handful of curmodgeons still uses it. What we'd be engaging in there is a kind of institutionalised finger-pointing. How sure are we that our fingers will be pointed only appropriately ? I think this kind of approach is going to cause more problems than it solves. Thanks for all your comments. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
