Re: mucking with dpkg control files in maintainer scripts?
Goswin von Brederlow writes ("Re: mucking with dpkg control files in maintainer scripts?"):
> Isn't it more accurate to say that the dpkg database is transaction
> based? Changes are recorded on the fly in updates and then commited
> attomically when the transaction is finished.
No. Updates written to /var/lib/dpkg/updates have been committed, in
the sense that dpkg has committed to them. If dpkg decides to abort a
package installation, it will not roll back by unwinding updates in
/var/lib/dpkg/updates, but by writing new later updates of the
package's state (which will be moving in roughly reverse to usual), as
dpkg rewinds the installation attempt as applicable. This ensures
that if dpkg dies, the whole system and status database are left in a
consistent (if perhaps undesirable) state.
> And dpkg honors the updates log when being called again while
> maintainer scripts poking around in the status file will not.
Those maintainer scripts are just buggy.
It would be simple to make a dpkg-query option to dump the current
status information to stdout but I'm not sure it's wise; it might
encourage maintainer scripts to use this information. Perhaps we
should make the invocation fail if run from a maint script :-).
Ian.
Reply to: