[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1011228: marked as done (Questions hold up upgrades.)

Your message dated Wed, 18 May 2022 17:42:05 +0200
with message-id <20220518154205.sfthlidiprpsbhp5@crossbow>
and subject line Re: Bug#1011228: Questions hold up upgrades.
has caused the Debian Bug report #1011228,
regarding Questions hold up upgrades.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1011228: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011228
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: apt 2.4.5 (amd64)
Severity: wishlist

I was upgrading my system and expected the upgrade to take about
an hour. So after the initial questions at the start I went off 
to do other things. When I came back there was a new question about
some file I had modified. 

IMHO it should be easy to make a dependency graph of the upgrade. 
Need to fetch packageX before I can unpack packageX and need to
unpack packageX before I can run the install scripts for packageX. 

And: dependencies dictate that packageX is installed for packageY. 
So we better finish installing packageX before we (unpack or run
the install script. Some thought will need to go into which one
is required) pacakgeY. (maybe unpacking can already be done before
we've run the install script). 

Now things are possible, like "start installing when the download
of "later" packages is still in progress. 
And: move the questions all to the end instead of having them
happen somewhere in the middle of a long install/upgraded. 

That more-or-less automatically happens if you continue to install
unrelated stuff should a question be asked. 

Possibly: for testing: you might write out the dependency tree
as a Makefile. 

all: installed_packageX

installed_packageX: unpacked_packageX
	run_installscript packageX 

unpacked_packageX: fetched_packageX
	unpacack packageX

fetched_packageX:
	fetch packageX

installed_packageY: installed_packageX unpacked_packageY
	run_installscript packageY 

unpacked_packageY: fetched_packageY
	unpacack packageY

fetched_packageY:
	fetch packageY


Running make will now intermixing fetching and installing whatever
can be installed. Adding -j 5 will allow overlap between the
different tasks, but fetching multiple packages at once may
be counter-productive (although... from different sites, that is
already done atm, right?) 

But if one task gets "stuck" asking for a question, 4 other threads
can continue to fetch, unpack and install packages that are not related. 

For final version. I do think that you need to handle the dependencies
and parallelism inside apt. There should be a single "asking questions" 
thread, and I don't know a good way to teach that to Make wile still
allowing parallelism on other stuff.

--- End Message ---
--- Begin Message --- 
On Wed, May 18, 2022 at 03:44:41PM +0200, Roger Wolff wrote:
> IMHO it should be easy to make a dependency graph of the upgrade. 
> Need to fetch packageX before I can unpack packageX and need to
> unpack packageX before I can run the install scripts for packageX. 

It isn't easy at all, but it is already done.


> And: dependencies dictate that packageX is installed for packageY. 
> So we better finish installing packageX before we (unpack or run
> the install script. Some thought will need to go into which one
> is required) pacakgeY. (maybe unpacking can already be done before
> we've run the install script). 

This as well, you are basically describing dpkg here without all the
details of Pre-Depends vs Depends and preinst, postinst, … scripts.


> Now things are possible, like "start installing when the download
> of "later" packages is still in progress.

Nope, you can't (easily) as the package you are upgrading while
downloading others could easily be one involved in keeping the
online connection breaking the upgrade process for example.

It is of course possible to change the tires of your car while you drive
on the highway, but it is neither easy nor adviceable in general.


> And: move the questions all to the end instead of having them
> happen somewhere in the middle of a long install/upgraded. 

Well, we prefer asking (debconf) questions beforehand, but that is sadly
not always possible. Its even worse for the type of questions you
complain about here (dpkg conf).


> That more-or-less automatically happens if you continue to install
> unrelated stuff should a question be asked. 

Unrelated is a big word. Are a game and a text editor unrelated? If they
are e.g. implemented in the same interpreted programming language
probably not. Or if they have some online feature. Or or or.


> But if one task gets "stuck" asking for a question, 4 other threads
> can continue to fetch, unpack and install packages that are not related. 

A typical problem is that Makefiles are missing dependencies, so with
enough threads or with less luck you are bound to run into failures,
hopefully big and flashy, but at times also silent miscompilations.
Nothing a 'make clean' can't solve, but you might not appreciate it
that much if apt ends with a "something went wrong, please reinstall".

It also turns out that packages are highly interconnected unlike typical
make targets which tend to be sparse and rather flat trees. But you
don't have to trust me, feel free to draw a map of the upgrade you were
performing. Its gonna be a nice picture I am sure and if not really
workable for apt probably a nice stress test for make at least.

You can btw look into EIPP, that is the External Installation Planner
Protocol, which APT supports so that you can write a tool to potentially
come up with a better plan than APTs current default planner has.

Probably more productive is looking into ways of reducing the occurrences
like preferring .d-dropin files rather than modifying main conf files if
possible and/or using dpkg options to force automatic choices for these
questions for example.

I have also to note that while a user sees these questions while running
apt and hence attributes them to apt, apt isn't really involved… similar
to how your TV isn't really responsible for the contents of the channel
displayed, even through you see that content while using the TV…

Anyway, as this bugreport isn't actionable I have to close it as such.


Best regards

David

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: