Re: apt .v. aptitude (was Re: how to remove exim4 without removing mysql-server?)
From: Brian Nelson (pyro_at_debian.org)
Date: Tue, 16 Nov 2004 01:31:35 +0000 To: email@example.com
On Tue, Nov 16, 2004 at 12:14:42AM -0800, Marc Wilson wrote:
> On Mon, Nov 15, 2004 at 01:54:19PM +0000, Brian Nelson wrote:
> > What dpkg does is broken. It has no business storing that stuff in the
> > status file.
> Now you're echoing Colin Watson.
And we all know what a poor source of wisdom he is... :p
> WHY is it that it has no business storing that information in the
> status file? A package's installation state should be there, but its
> hold state should not? Oh, by all means, we should have to look in
> more than one place for information about the state of the package.
dpkg itself doesn't care about holds. Try using "dpkg -i" on a held
package and see if dpkg gives a crap about the hold. dpkg is a very low
level tool that is used for installing and removing packages, and that's
about it. A hold is a desired state, whereas dpkg should and generally
does only deal with the actual state.
A package hold belongs somewhere closer to the realm of the dependency
> As for it being broken, dpkg is the fundamental package installation tool.
> If its behavior is broken, heaven help Debian. If its behavior needs to be
> changed, then by all means, let it be changed.
Why should it be changed first? It should be superseded and then
> > Consider aptitude to be, errr, "ahead of its time".
> Consider aptitude to be attempting to define a new standard. Will dpkg
> begin honoring what aptitude does? It hasn't so far.
dpkg shouldn't care how aptitude stores its hold states.
> > dselect and apt-get are both dead-end tools whose development was
> > largely halted long ago. If you rely on them to define the "standard",
> > you're never going to get anywhere.
> I don't rely on dselect and apt-get to define the standard, I rely on dpkg
> to define the standard. Dselect and apt-get follow that standard, aptitude
> does not, hence aptitude is broken, or at least should not be promoted as a
> replacement for tools that DO.
dpkg itself doesn't even follow this "standard".
> Can aptitude rebuild the available file? No, I didn't think so. Guess
> dselect isn't all that useless.
I don't think aptitude even uses the available file at all. AFAIK, it's
strictly a dselect thing.
> I understand perfectly well why everyone fawns over aptitude... it's
> "dselect backlash".
I used dselect for a long time before I used aptitude, and I liked it.
I switched to aptitude because I found it to be more powerful.
> > > If aptitude is *inconsistent*, as it is between the command line
> > > and the ncurses interface, it's WORSE.
> > The command-line is an after-thought in aptitude. It's not intended to
> > be used as the primary interface and is not as well supported.
> That is not a reason for its behavior to be different. Why does dependency
> resolution depend on the interface presented to the user?
Because of a bug.
> Please provide a reference for your claims regarding the command-line
> interface being a second-class citizen. According to the changelog, it's
> been there for over two years, and is continuing to be enhanced (changelog
> entries for 2004 refer to it). If it's not going to be supported, it
> should be ripped out again.
It's supported, but I get the impression the maintainer is much less
interested in it. His main interest lies in the expandable/contractable
hierarchical browser thing. He's stated this publicly before--sorry,
don't have a link.
> Apparently you think enough of the command-line capability to contribute to
> official documentation promoting its use over other tools. This is...
I don't promote aptitude in particular; I just discourage the use of
apt-get, especially for newbies. I don't think aptitude is a
particularly good choice for newbies since its interface can be as
vexing as dselect's at times. Still, it's better than apt-get.
My contribution to the documentation in question is that if you use
aptitude as your primary tool, you should use it for everything and not
mix with apt-get/dselect (since you mess up the auto-dependency
> > The inconsistency is a known bug, and it'll be fixed some day. It's not
> > a high priority though, and certainly isn't something that should
> > prevent aptitude's use at all.
> Considering the maintainer's attitude, it's unlikely it'll ever be fixed at
> all. Why it's there to begin with....
Quoting the maintainer, "it's probably a side effect of the way the
command-line initializes the backend (it doesn't select as many things
automatically, so that things like single-package installs work)."
The maintainer doesn't have any particular "attitude" that I'm aware of,
other than he's mostly satisfied with aptitude and has scratched most of
his itches already. He's put out several public calls for help. If
you're so interested in improving the command line interface, maybe you
could volunteer? :)
-- For every sprinkle I find, I shall kill you! -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org