Peter Samuelson <pe...@p12n.org> writes:
> [Simon Chopin]
>> But I believe what Stanislas mean is to unpack while downloading the
>> rest of the packages. I often wondered why it wasn't the case, but
>> I've assumed so far that there was probably a reason I just could not
>> think of :)
>
> I think it is because, in the general case, it is not at all obvious
> that applying _part_ of the scheduled upgrade will leave the system in
> a working state, and a state the user would approve of.
>
> For example: say you are upgrading package A, but the new version of A
> conflicts with package B1, so you are also replacing B1 with B2. So,
> what apt will do:
>
> Download A
> Download B2
> Remove B1
> Upgrade A
> Install B2
>
> Now assume "Download A" has finished, but "Download B2" is still in
> progress. You could upgrade A, which involves first removing B1
> because of the conflict.
>
> Now assume B2 fails to download. You are left with a system where
> neither B1 nor B2 are installed. Is that what the user would want?
What you actually have is
Remove B1
Unpack A
Unpack a million other packages
Unpack B2
Configure A
Configure B2
There already is a sometimes large window without B1. So I don't see
that as a real issue.
Anyway, there are many cases where you don't have a
conflict/replaces. Also for large upgrades the space required in /var is
huge. If apt could download and install in parallel it could also clean
up its cache in parallel reducing the amount of space needed.
One other thing that could happen in parallel: pre configuring.
While apt downloads it could already trigger the
/etc/apt/apt.conf.d/70debconf hook (DPkg::Pre-Install-Pkgs). That way
the user could answere questions while waiting for downloads.
That should actually be quite simple to implement.
MfG
Goswin
--
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/871v3mwq15.fsf@frosties.localnet
