Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi all,
2010/4/9 Jonathan Nieder <jrnieder@gmail.com>:
> Guillem Jover wrote:
>
>> I've not checked but I'd
>> expect this would imply only few lines of code on the apt side, just
>> removing the just disappeared package from the to be configured queue.
>
> >From my reading of pkgDPkgPM::ProcessDpkgStatusLine, APT does not
> care much about statusfd. It is treated as just some information
> about progress to pass to the end-user.
APT only processes the line to add progress information and to translate
the status changes so it doesn't need to be translated in every frontfrontend
again. If both would be done in dpkg we (as in APT and Co. ) frontbackends
could simply pass it through to someone who has real interest in it.
> Currently, this map does not affect APT’s order of operations.
> Instead, the list of operations is planned in advance and followed
> rigidly, regardless of the situation in the field.
If i would have something to say i would push the complete planing in which
order packages need to be configured to dpkg which i tried with my
no-triggers options and succeeded to some extend:
The only problem is that packages doesn't run awaited triggers of their pre-
dependencies on unpack while configure does it for dependencies (#526774).
With a few options enabled APT does only unpack all the stuff and
configure -a at the end -- with the exception of the bug (?) above and
packages it applies immediate configuration on, but these could be also
configure -a calls instead of an explicit naming of the packages…
(still the progress reporting need to be solved which is the sole reason
the options aren't per default on already as they work otherwise and
even avoid some problems…)
My personal dream is it that APT would call dpkg with a list of packages
the user want to see installed and/or removed/purged and dpkg would
figure out an order in which the packages need to be unpacked/configured or
removed as it has some informations handy which APT simply has not:
The disappearing is one simple thing, but it can also provide better progress
information as it knows which triggers are still awaiting and it even could
break circular dependencies as it knows which packages have maintainer
scripts which is again knowledge you can't easily transport to APT.
> A high-level package manager that collaborates with the user to deal
> appropriately with problems as they come might be a lovely thing.
> apt-get uses a simpler approach: to fix problems, you run it again.
APT has a Dpkg::StopOnError option which defaults to true and in the false
case simply proceeds with the next action as nothing had happened before,
but if something failed in a maintainer script or dpkg
APT can't do much to help the user anyway:
The user needs to deal with the error as the program who knows best how
to deal with the error (= the maintainer script or dpkg) has already given up.
If they can't solve the problem, how APT could do it…
Oh, and in a stable environment this shouldn't happen *knocks on wood*. :)
The only countermeasure APT takes is to apply immediate configuration for
essential and important packages (=unpack it and immediately configure them
before starting to do work on unrelated optional packages).
> The idea of the proposed patch is to allow front-ends to make the same
> assumption.
Only fair, but Guillem is right, APT already uses enough --force flags…
It should be possible to dequeue the configure call based on the status-fd
(i will give it a try now) through it feels a bit wrong and
remembers me of my dream from above. ;)
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
Reply to: