Colin Watson writes:
I do sometimes wonder why we don't relax the definition of "safe" upgrades to include installing new packages but still not removing old ones. I know that many of my uses of dist-upgrade are just for when something grows a new dependency that I didn't previously have installed.
That's a good question. Like many things in aptitude, the basic
design was copied from apt-get, and I haven't thought much about it
since then. But in fact, I think this makes a lot of sense, and it
turns out that it's fairly easy to acheive.
I've just checked a change into head that makes safe-upgrade allow
new packages to be installed. This is accomplished using aptitude's
dependency resolver, restricted to only consider holding packages back
or installing the candidate version of a package (that is, the version
that aptitude install would choose by default). If the resolver
produces a solution, it's applied blindly; otherwise we fall back to
the current behavior (and probably fail). The current behavior is
still available through aptitude --no-new-installs safe-upgrade and
the configuration option
Aptitude::CmdLine::Safe-Upgrade::No-New-Installs.
The one thing that might get missed are broken recommendations --
libapt doesn't consider these to be broken dependencies, so
aptitude won't notice them unless there are broken real
dependencies. These will get fixed in full-upgrade because it uses
apt's resolve trivial dependencies
algorithm. That's probably
what's
doing the wrong thing with conflicts,
but it also has logic to do the right thing
with new
recommendations. Regardless, those wouldn't have been fixed by the
old logic of safe-upgrade, so this is not a regression.