Re: apt-get vs. aptitude
On Sun, 2013-10-13 at 12:24 +0200, Morten Bo Johansen wrote:
> On 2013-10-13 Dmitrii Kashin wrote:
>
> > I think that aptitude works quite well for the easiest cases. And it is
> > the only instrument I know which allow to see dependency chains. It was
> > dselect some time ago which could do it too as I know, but now it seems
> > to be dead. BTW, it provides with good capabilities for searching
> > through packages.
>
> Remember that aptitude has evolved quite a bit. The scenarios that you
> and some others describe are not necessarily pertinent anymore. When you
> use phrases like "fond memories", please state how old these memories are
> ;). Any package manager, needless to say, is wholly dependent on the
> metadata in the packages, so if these are not sensible, they may come up
> with rash solutions. The great thing about aptitude (to me) is that it is
> so easy to leaf through "broken" packages, using the 'b' key in the
> curses interface, and then examine what the matter is with each package.
> Most often, I find that I can solve dependency problems by simply not
> upgrading one or more packages. You do that easily by typing 'v' on a
> broken package and then typing '+' on the already installed version. If
> using the resolver instead, the solution presented is often to remove the
> package or some other package. For instance, at the moment the package
> xul-ext-greasemonkey is marked as upgradable on my system, but the
> package's metadata has Iceweasel in a non-installable version as a
> dependency. Aptitude wants to remove xul-ext-greasemonkey and apt-get
> wants to remove Iceweasel. None of these solutions may be what you want,
> so simply keeping xul-ext-greasemonkey in the already installed version
> is an alternative that the command line solutions in the two package
> managers do not present the user.
>
> Morten
apt-mark hold <package>
or
echo <package> hold | dpkg --set-selections
or
Synaptic's lock option
will lock the packages for apt-get.
Reply to: