James Vega <james...@debian.org> writes:
> On Mon, Jan 17, 2011 at 12:43 PM, Bjørn Mork <bj...@mork.no> wrote:
>> My claim is that packages like unattended-upgrades and pm-utils are
>> completely unrelated to each other, and that a hook in
>> unattended-upgrades which breaks pm-utils by preventing hibernation is a
>> critical bug, even if the breakage seems intentional.
>
> Is this just a case of an upgrade pulling in a new kernel, which could
> cause pm-hibernate to disallow a hibernate[0]?
No, that one I can understand. If the kernel changes, then you have to
reboot before you can hibernate. But that is part of the kernel upgrade
hooks and not really related to how the kernel is upgraded.
This is what I find unacceptable about unattended-upgrades:
case "${1}" in
hibernate)
python
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
;;
where the /usr/share/unattended-upgrades/unattended-upgrade-shutdown
script is documented as
# unattended-upgrade-shutdown - helper that checks if a
# unattended-upgrade is in progress and waits until it exists
So you have to wait for this job to finish before hibernation will
succeed. This may take significant time. When I push the hibernate
button, I expect the system to be frozen and hibernated as quickly as
possibly. I do not want for any random process to finish its work.
My claim is that *any* package installing a program which may be running
at hibernation time just as well could install something similar. There
is nothing special about the unattended-upgrade job which could possibly
justify that you need to wait for it to finish. It should be frozen
like any other process, and thawed like any other process on resume.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vyj8gt1....@nemi.mork.no
