Re: cupt: does not run triggers before unpacking reverse-pre-depends
Eugene V. Lyubimkin wrote:
> On 2011-02-07 03:46, Jonathan Nieder wrote:
>> dpkg: regarding .../inn2_2.5.2-2~squeeze1_amd64.deb containing inn2, pre-dependency problem:
>> inn2 pre-depends on inn2-inews (>= 2.3.999+20030227-1)
>> inn2-inews is unpacked, but has never been configured.
>> dpkg: error processing /var/cache/apt/archives/inn2_2.5.2-2~squeeze1_amd64.deb (--unpack):
>
> So, am I right you ask for implementing a workaround for #526774?
Thanks for a reminder --- something like that. I haven't worked out
whether there is a dpkg correctness bug here. There are certainly
usability and documentation bugs.
>From doc/triggers.txt:
Status Pending Awaited Satisfies Remedy
triggers triggers Depends
unpacked never maybe No postinst configure
c.-failed never maybe No postinst configure (when requested)
t.-awaited yes always No postinst triggered + fix awaited pkg(s)
t.-awaited no always No fix awaited package(s)
t.-pending always never Yes postinst triggered
installed never never Yes n/a
Triggers are not part of policy[1] yet. But anyway, this requirement
seems sensible --- a package in python triggering python-support, for
example, is not usable until python-support creates some symlinks as
requested.
The usual UI for satisfying unpack-time dependencies is that dpkg
leaves it to a higher-level package manager. A higher-level package
manager makes sure the pre-dependencies are fully installed before the
pre-dependent packages are unpacked and dpkg only checks this.
This is in contrast to configuration-time dependencies for which
ordering of triggers is taken care of automatically by
dpkg --install/--configure (though I haven't checked the details.
I would hope --no-triggers would mean that the triggers-awaited state
would percolate through the dependency tree, but I couldn't find code
for that).
The upshot: iiuc one needs to run
dpkg --triggers-only <packages pre-depended upon>
to satisfy an unpack-time dependency, by design.
Hope that helps,
Jonathan
[1] http://bugs.debian.org/582109
Reply to: