Re: potato -> woody upgrade not smooth...

[tytso@mit.edu]

On Wed, Jul 11, 2001 at 11:06:17AM -0400, Sam Hartman wrote:
> 
> The Apt developers have I think rightly argued that this would be a
> layering violation.  apt-get was never really intended as the primary
> packaging tool that a lot of users would use.  The hope was that
> people would use tools like aptitude or console-apt.
> 
> However people really seem to want a CLI tool.  It's not clear how to
> deal with recommends well in a CLI.

A whizzy curses based interface or even the whizzy X-based interface
is completely useless if people can't accomplish common tasks easily. 

So think about common tasks:

	1) I want to run program "foo", or I want to install a program
		that does "foo", but I don't know the appropriate
		Debian package name(s) that I need to install.  What
		do I do?  (i.e., the equivalent of apt-cache search)

	2) I want to install the debian package "foo".  (i.e., the
		equivalent of "apt-get install <foo>").  Ideally this should
		ask me if I want to install the suggested or
		recommended packages, but this isn't as important.

	3) I want to upgrade my machine to the latest woody packages.
		(i.e., the equivalent of "apt-get update"; "apt-get -u
		upgrade"; apt-get -u dist-upgrade".  (Hopefully with
		support for recommended packages, and hopefully with
		support with displaying in advance what packages will
		be upgraded and what has been changed --- i.e.,
		apt-listchanges --- all automatically).

The problem with dselect, aptitude, or even the whizzy Gtk-based Storm
package manager don't make it easy to do this.  (i.e., I just want to
install one package; why should I have to wade through thousands and
thousands of packages to find it?)

> If you have ideas on how to present the interface they would
>  certainly be welcome.

Well, how about this.  There should be *one* program that people use
as a common CLI front-end interface.  Let's call it "apt" for now.
Users don't care about layering violation; they just want to an easy
to user interface.  Users shouldn't have to twist their thinking to
the details of the implementation, after all.

1)  So "apt search" will do the equivalent of "apt-cache search".

2)  "apt install" will do the equivalent of "apt-get install"

3)  "apt upgrade" will do the equivalent of "apt-get upgrade"

4)  "apt reconfig" will do the equivalent of "dpkg-reconfigure"

5) "apt help" will tell the user all of things they can do.  (Imagine!
People will actually find out about the fact that you do the
functionality of dpkg-reconfigure without having to stumble across it
by accident!!!  It's sort of like Boston-area towns deciding to put up
street signs at complex 6-way intersections from hell; it completely
ruins the game of keeping outsiders completely and thoroughly lost.  :-)

To handle the suggested / recommended packages, I'd suggest an
interface where when the user does an "apt install" or "apt upgrade",
apt displayes all of the suggested and recommended packages:

<tytso.root@think>	{/usr/home/tytso}, level 4
513# apt-get -u dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following NEW packages will be installed:
  krb4-config 
The following packages will be upgraded
  libzephyr3-krb 
The following packages are suggested
  krb5-users krb5-config
The following packages are recommended
  krb4-config
Install all suggested packages? [Y/n] n
 Install krb5-users? [Y/n] y
 Install krb5-config? [Y/n] y
Install all recommended packages? [Y/n] n
 Install krb4-config? [Y/n]

If the user answers "y" to the "Install all suggested/recomended"
packages, then apt won't ask on a per-package basis.  So from a
convenience point of view, it's very easy to accept all of the
recommendations.

					- Ted