Bug#624618: apt: Maybe time to modernize APT package description

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Justin B Rye wrote:
> David Kalnischkies wrote:

>> The package apt provides more than just apt-get and apt-cache -
>> even through these are arguable the most prominent.

Makes sense.  Quick reactions:

>                                                     We don't have to
> state that APT officially stands for Advanced Package Tool, but
> "Debian's advanced package tool" makes a perfectly fine package
> synopsis regardless (hence my comment about deniability, though I
> don't see why it's so crucial to be able to pretend that it's
> user-hostile gibberish).

The problem with "advanced" is that at first glance APT is only fancy
relative to dpkg.  I suppose that sets up a good angle for the long
description --- convince the reader that this can compete with the
likes of yum!  (I'm kidding; please don't hurt me.)

>> This package provides the common ground for searching and
>> managing packages as well as information about packages
>> other package managers can be depend upon.
>
> I agree with the idea of introducing the APT infrastructure as a whole
> first, but I'd rephrase it to be clearer about the layers (and leave
> the features it provides for the next paragraph).  Maybe:
>
>   APT provides mechanisms for package management tasks, relying on dpkg as
>   a back-end and providing an infrastructure that other tools can build on.

Seems a bit vague.  What is APT, anyway --- is it a library?

http://wiki.debian.org/Apt says:

	Apt (for Advanced Package Tool) is a set of core tools inside
	Debian. Apt makes it possible to:

	* Install applications
	* Remove applications
	* Keep your applications up to date
	* And much more...

	Apt, which basically resolves problems of dependencies and
	retrieves the requested packages, works with dpkg, another
	tool, which handles the actual installation and removal of
	packages (applications). Apt is very powerful, and is
	primarily used on the command line (console/terminal). There
	are, however, many GUI/Graphical tools to let you use Apt
	without having to touch the command line.

	At the present time, aptitude is the recommended tool for
	interaction with the APT suite. APT tools should be used for
	specific management actions that may not be covered by
	aptitude, or where the latter behaves more aggressively with
	dependencies.

Wikipedia has something nice to say:

	APT was originally designed as a front-end for dpkg to work
	with Debian's .deb packages, but it has since been modified to
	also work with the RPM Package Manager system via apt-rpm.

Cupt does not declare a dependency on APT.  Today if I read the code
correctly it relies on /var/lib/apt existing but I suspect that's just
a small oversight.

I suppose if I ran the world, the package description would start
with something to the effect that

	APT was originally designed as a powerful front-end for dpkg;
	nowadays a variant named apt-rpm is also available for use on
	non-Debian systems that use the RPM Package Manager.

Please don't take my wording too seriously (unless you are fixing it,
in which case please take it very seriously).  This is a sketch.

>> This package provides the common ground for searching and
>> managing packages as well as information about packages
>> other package managers can be depend upon.

	APT can be used to install or remove packages by name and is
	responsible for resolving dependencies and retrieving the
	appropriate version of the requested packages.  Unless
	configured otherwise, it will authenticate the sources of the
	packages it uses and always validates the retrieved data.  To
	support this work it maintains information about packages in a
	format optimized for fast information retrieval.

Even people who don't use APT's package management features
day-to-day (maybe they use dselect?) would find its searchable package
cache very useful.

[...]
> Now that you mention it, yes, it definitely deserves a bulletpoint for
> the authentication part... but could we add a reference to "knowing
> which version you need, and where to get it"?
>
>   It supports:
>    * searching for package information;
>    * resolving package install requests, finding the appropriate version
>      in the archives;
>    * fetching packages along with all their required dependencies;
>    * authenticating the sources and validating the retrieved data;
>    * installing and removing packages on a working system.

This wording is much better than what I wrote above.  The
bulleted-list form makes it hard to read straight through, though.
Maybe:

	This package contains several command-line tools, of which the
	most prominent are apt-get, which installs and removes
	packages by name (transparently resolving package dependencies
	and conflicts, finding the appropriate versions of packages in
	the archives or on CD, and downloading and authenticating
	them) and apt-cache, which can be used to search for package
	information.

	It also provides a libapt_pkg library exposing this
	functionality for use by higher-level interfaces like aptitude,
	synaptic, wajig, and upgrade-system.

By the way, why isn't libapt-pkg in a separate (versioned) package?
It would make transitions a little easier.

[...]
>> - apt-config as an interface to the configuration settings

I guess it might be worth sneaking it somewhere that APT is highly
configurable, that APT can be used as a dselect backend, that APT
can easily be extended to learn additional protocols, and that to
install a package from a .deb, the user might want gdebi instead (by
the way, why doesn't apt do that?).

Thanks and hope that helps.

Regards,
Jonathan