Re: Premature aborts in apt again.
On 10 Apr 1998, Manoj Srivastava wrote:
> Jason> I'm not sure it is as large a deal you make it out to be,
> Jason> sendmail has been deconfigured for a long time, what is a few
> Jason> more mins while the buggy script is fixed?
>
> It is a bigger deal, I think, than I made of it. There is no
> buggy package. There are no buggy scripts. Sendmail is
> perfectly fine.
How did a corrupted archive get into the distribution!? That certainly
should never have happened!
> This means I can not use apt to upgrade my package until the
> archive has a non-broken copy of this package. There is no reason to
> stop dead just because md5sums did not match for *one* package, and
> leave important packages unconfigured and not running (sendmail is a
> fairly important package for any site).
Fire up dselect and hold the package.
> In fact, any non-essetial package shall be left hosed by apt!!
Unconfigured is not hosed, it is simply unconfigured. If you fix the
problem it will happily continue, an extra minute is not that big a deal,
an upgrade can easially take longer than a few mins and during that time
sendmail will be left unconfigured because we decided it was best to
configure at the end.
It can be done better, it's just not trivial nor exeedingly important that
it cannot wait. As you said you can always run dpkg --configure -a if you
want sendmail configured now. As a hack I could add a call to dpkg
--configure -a in the event of a failure, but that might create more
possibilities for failure..
The worst bit is that your specific example I can do very little about
because there is no way for dpkg to communicate that a specific archive's
unpacking failed (well, depending on how far it gets..), so I can never
know what went wrong. I haven't looked in much detail but I think most of
the other failures are specificly recorded so I can tell what went wrong,
but it is possible that some are not.
Maybe for now I should just ignore failures from dpkg and blindly continue
- relying on dpkg's error checking to not hose things too badly. That is
done already anyhow because dpkg doesn't abort on an error, it blindly
continues till the end of the command, in some cases generating more
unreleated errors and confusing the user.
The big thing is that without (possibly major) changes to dpkg I can't do
this perfectly, everything is a baind-aide patch.
So, I can apply 4 `fixes'
1) Attempt to deduce failed archives and devise a mechanism to rebuilt
the target state to cookie-cutter around the problem. This is the
best solution, but is very difficult (possibly impossible for some
cases) to do with the current dpkg setup
2) Run dpkg --configure -a after a failure to silence complaints that
things are left unconfigured. This is bad because configure's will
fail and the user will get confused thinking there are more errors
3) Blindly continue and try to finish off the sequence, in some cases
this will work great, in others it will damage the system, in still
others it will generate massive failures in all other packages.
-- Consider bash failing, -EVERY- other package fails in this case
I was extremely happy that apt aborted after the bash install
failed, the result had it not would have been awefull
4) Change the ordering sequence so that failed packages sink to the end
of the list. This might work well, but still has alot of problems,
namely you have to run the command twice or more. It also cannot
fix your problem with a corrupted archive. Also since dpkg does #3
for it's command list this will fail in alot of cases.
The solution is 1, with a proper interface to the installation mechanism
that gives immediate feedback on all operations including detailed error
summaries - then I can do an awefull lot to make things better.
Jason
--
To UNSUBSCRIBE, email to deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: