Le 11.06.2014 08:41, John D. Hendrickson and Sara Darnell a écrit :
berenger.mo...@neutralite.org wrote:
Le 08.06.2014 17:10, The Wanderer a écrit :
Maybe it's possible to configure aptitude so that it doesn't do
that...
but if so, I would think that configuration should be the default,
because as things stand it seems almost worse than useless for
anything
but the simplest operations.
Can't agree more about the aptitude's "solver". That's why I
**never** use it, I prefer to break packages, and then fix the system
myself, through the curses interface.
Since I am running a fairly minimal system ( in average 800-900
packages are installed on my computers ) it does not take ages, even
if the aptitude's solver makes things very slow when something is
broken ( it tries to find new solutions after every user action, even
moving on next broken package ).
I tried to go into it's source code, but I was not able to
understand it's structure. At least I learn that, at a point in time,
there was a Qt port, a Gtk port, and another one that I do not
remember. But it's hard to find a point to start hacking it
unfortunately.
It have other defaults, for sure, for example since multiarch
browsing packages is painful if you have more than one arch: every
package corresponding to your pattern will be found as many times as
the number of architectures you enabled.
Another one is the CHANGELOG system, which only retrieves Debian's
changelog, which is not really informative about what was changed in
source code: lot of "maintainer change", "contributor added", etc. It
is also impossible to select text from it to copy paste, and suffer
various limitations when you are downloading/installing stuff: you can
not then change state of packages, there is no possibility to install
a package at the point where all it's dependencies has been
downloaded, or better to unpack it while waiting ( in short: it is
mono-threaded ), it can not install things in a different place than
system's defaults ( unlike dpkg which is able to, so it's not a dpkg's
limitation, and it would make it possible to manage distant computers
by mounting their partitions through sshfs or whatever. Or why not,
manage multiple computer at the same time, but this would be a lot
more complex of course. ).
And finally, it would be pretty nice if it had different colors
depending on the version increase: major, minor, build.
But no software is perfect, right? Apt-get can't do those things
either, and I bet the same for synaptic.
So I still prefer aptitude ( for it TUI, clearly ), and maybe in the
future I'll have more motivation to enhance it than last time I tried
( but it's not even possible to find correct documentation about
libpkg, IIRC, so I doubt it ). Or to prove another time that
http://xkcd.com/927/ is so true :D
However, about the solver, I have noticed ( when I was trying to
hack it, I subscribed to the dedicated mailinglist ) that the idea of
a multiple solver was there. With this feature, implementing a null
solver, or whatever, would be possible. Our "toys" are not
unmaintained.
NO. APT does not break packages as far as i know.
point is. NO. aptitude is going fast. it is a long problem to
solve
!!! SEE BELOW for how to make it really fast !!!
apt-get doesn't have a wishlist picker (see below) neither does dpkg,
that is why they are "faster".
how do i know?
------------------------
aptitude has a feature which tries to choose whish lists when there
are multiple choice paths to try (some or all of which may not
comprise the subset you need, it's complicated). I read the C++
code,
and errors i've not heard of aside: it's picker is theoretically
good.
i wrote this debian tool(s)
http://sourceforge.net/p/dep-trace/
it installs removes etc like apt-get and dpkg BUT also has a
auto-chooser which asks user to make choice if necessary. (see the
page ^^ it has new features i won't describe here). dep-trace goes
"faster" (simpler resolver) but can't do wishlists like aptitude.
dep-trace slower than dpkg round-trip install but designed to be far
faster for given larger lists of pkgs.
back to point. point is. NO. aptitude is going fast. it is a long
problem to solve.
========================================
!! TADA i got an answer that will make you speedier that you were in
the 1990's !!
reduce the size of your /var/lib/dpkg/available. HOW ? well just
open the file and delete stuff and save ! ok. there are too many
ways to choose how. back up before doing it. and don't delete any
you'll need (ie, dependancies)
obviously: don't install extra CD's you don't use (ie, non-free) they
will bloat the "available" file.
also: check /etc/apt/preferences (debian docs) about if there's an
option to filter updates/paths of "available" packages.
(if you don't have the file make aptitude export it, it won't unless
asked). file is also made by delect(1) update available choice.
obviously you need tools (dep-trace has some, debian many more) to
help you grep which available to drop, to sort things out
dep-trace could tell you which you are not depending on
/var/lib/dpkg/available is actually a catenation of many Packages
files on ftp.debian.org found in directories. you might exclude
whole
directories would be another approach
"DISTRIBUTION". well what a distro is is a set of packages that are
all known, as far as dependancies go, not to conflict.
so really when you take it upon yourself to remove packages from
"available" your in effect making your own distribution (source
compiling aside). so definetly keep in mind you may need to restore
the original, maybe you MUST install something and dpkg says it's
unknow because your new availble doesn't have it. and etc
---------- dep sorting is not np-complete ----------------
speed: dep-trace solves all deps of all installed almost
instantaneously, while dpkg or apt only solve a subset and don't know
all they need to. then why isn't dep-trace faster? well #1 it does
some list choosing/selecting like aptitude. but mostly it's because
parsing the 40mb data into logic that's needed is lengthy: and must
work without using much software** dep-trace is in sh(1) and awk(1)
and doesn't have the array speed. but even if it did: there'd be a
speed problem.
there's definitely a speed problem. it's a lengthy problem that just
grows. one cannot keep growing the "available" file with more pkgs
and more deps. it has to be split into sections at some point so you
get the wait times you volunteer for. you can't database it thinking
delaying the problem will suffice.
debian admins should consider "easy ways" to filter what gets in the
"available list" until user asks for more. there are some already
none come to mind at the moment.
**(ie, dpkg cannot use octave(1) for solving since that has
dependancies and isn't installed before dpkg, dpkg installs it! well
ok could if made to be so, but no one has a standard simple base that
does that, and if they did there'd be no backport which would be bad,
and etc)
I might be wrong, but removing stuff in /var/lib/dpkg/available will
have to be made after every update, and, personally, I try to often
update.
Plus, yes reducing that file will help, but it is only a workaround.
Aptitude's interface should no be frozen when it tries to find
solutions, and especially when a user's action have no impact on
currently known list of solutions.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/ce0c0cb994b32954800b2ee7a54de...@neutralite.org
