Re: Aptitude's reinstall
On Sat, Dec 29, 2007 at 01:35:40PM -0500, "Douglas A. Tutty" <dtutty@porchlight.ca> was heard to say:
> On Sat, Dec 29, 2007 at 08:30:15AM -0800, Daniel Burrows wrote:
> > On Fri, Dec 28, 2007 at 04:04:02PM -0500, "Douglas A. Tutty" <dtutty@porchlight.ca> was heard to say:
>
> > Just to clarify, the problem isn't just that aptitude doesn't have a
> > state for "reinstall". It actually did at one point (#167236, #121346),
> > but there's no way for aptitude to find out from the dpkg/apt layer
> > whether a reinstall that it requested actually took place. (ideally the
> > reinstall state should persist until the reinstallation is performed,
> > then be removed) Without this information it has to either arbitrarily
> > preserve all reinstalls, or arbitrarily drop all of them, and after
> > getting the bugs referenced above, I decided that dropping all of them
> > was a less annoying behavior.
> >
> > Usually aptitude figures this sort of thing out with an after-the-fact
> > examination of package states, but since a reinstallation leaves
> > packages in the same state that they started in, this won't work to
> > detect reinstalls.
>
> Why not have aptitude: 1) retrieve the deb(s) required; 2) deinstall the
> package and verify that it is no longer installed; 3) immediatly
> reinstall the package and verify that that it is now installed.
>
> Currently running programs won't be affected, only attempts to run new
> instances while the reinstall is happening.
In a Turing-complete universe, all things are possible [0]. That
doesn't mean that all things are necessarily easy. :-)
What you describe could be done. It would add a layer of complexity
to the download-and-install process, though, which means another piece
of code to maintain and another place for things to go wrong. It also
would change the semantics of "reinstall", which is currently a fairly
safe operation equivalent to "apt-get --reinstall" or "dpkg -i" on the
.deb file. Removing and re-installing the package is a much higher-risk
operation. Just off the top of my head, you would have to worry about
some of these:
* If a package's preinst or postinst script fails, step (3) will fail
and the package will end up in the "removed" state.
* If a package's postrm fails, it will now be in a half-installed
state. This can be recovered by the re-install, but now we've gone
through an error state when we wouldn't have in the past (possibly
with whatever the postrm was supposed to do left undone).
* If aptitude is interrupted between steps 2 and 3, the package will be
removed from the system and not re-installed. Running aptitude again
will presumably fix this, but other parts of the program (e.g. the
auto-removal logic and the problem resolver) may need to be taught
about the "re-installation" so they don't do the wrong thing, such as
removing dependencies of the package being re-installed or trying to
install Recommendations.
Just flagging the package for install immediately upon startup might
work to solve this.
* All the above has to be considered in light of the fact that other
packages may depend on the package being removed, so if something
goes wrong with it apt will consider *them* broken as well. Care
will have to be taken in the code to ensure that nothing improper
happens as a result of this. Also, no other apt tool will know
about this special state, so they'll just plow ahead and try to fix
broken dependencies however they usually do.
* If multiple packages are being re-installed, or a package is being
re-installed as part of a larger operation, there may be surprising
interactions between the re-installation and other parts of the job
being run. For starters, it will be necessary to perform the
initial removal before any other actions, so that the package will
be (hopefully) unpacked by the time that any of its dependers are
configured.
Those are the catches I can think of in about 5 minutes. I assume
that there are more side-effects of this behavior lurking in the
shadows that I haven't thought of yet; that's usually the case.
I don't really see the minor gain in convenience that this feature
provides as being worth the effort that would be required to implement
it, and the future effort needed to maintain the changes that it would
introduce. It might be useful, but there are many things that I think
are more useful to add to the program and that don't seem nearly as
likely to introduce unforseen and/or surprising-to-the-user effects.
With all that said, it's entirely possible that I'm overstating the
complexity of the problem and that there's a 5-line change that would
implement this in a self-contained and robust way. I'll be happy to
apply it if it appears.
Daniel
[0] Some restrictions may apply; offer void where incomputable;
consult your local computer science textbook for details.
Reply to: