|No, I’m quite sure I didn’t mean foster and not orphan. There’s a bug in 1.2.2’s parameters to Feta’s internal run() subroutine, which makes it try to execute multiple commands rather than remove all the packages. The contents command is also pretty broken because of a duplicate push call. Both these bugs are mentioned on the Feta web page, too – I put them there (and I put them in Feta, although not on purpose :P).
Anyway… If I was a user (which I am), I wouldn’t (don’t) like calling a help desk for information on how to perform a simple task like upgrading or installing software (which is why I greatly prefer APT/dpkg to Windows).
A console, keyboard-driven file manager, although incredibly useful, is not very novice-friendly. Plus, this still doesn’t solve the problem of integrating all the tools into one simple program it’s easy to teach someone to install something, or list something. It’s harder to teach them to do all those things.
The primary difference between user documentation and developer documentation is that user documentation is task based, instead of reference based. A user doesn’t want to look through a list of all commands to find “install”, they want to look through a list of what a program can do until they find “Install Packages”. Actually, this contrived example seems stupid, so how about wanting to look up “Making Text Bold” instead of ““. No user is going to guess the second one if they want to do the first one.
This same principle needs to be applied to interface design. To a user, there’s no difference between installing a local or remote file, there’s no real difference between that and removing package, and searching through packages should be there too, because all 4 things have the word “package” in them. A developer can see the difference; a user can’t, and shouldn’t have to. Not only do they want one tool that does all this, it shouldn’t be a file manager, because from a task-based point of view, copying/deleting/opening files has nothing to do with packages.