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. > Not. 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 resolver--i.e. APT. > 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 changed afterwards. > > 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... > confusing. 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 tracking). > > 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
