Debian mirrors and sources.list selections

[Drake Diedrich]

On Thu, Jul 04, 2002 at 10:35:48AM +1000, David Gibson wrote:
> I checked (which was a while ago) it didn't have the "suggests" and
> "recommends" categories of deb, but that's not necessary for apt to
> work (in fact it's potentially confusing).  Last I checked it also

   apt ignores Recommends: and Suggests:.  Only the higher level UI's
intended for human interaction show these (dselect, deity, ...).


> didn't have "or" dependencies (depends on (exim | sendmail | qmail |
> smail)).  But Red Hat's packages are structured to avoid needing them
> so much (by more aggressive use of "provides" and virtual packages).
> 

   The need for aggressive Providing: is caused due to a lack of aggressive
subpackaging and determination at buildtime of the package names/versions of
the dependencies.  Debian pushes most dependency information into the
name/version of packages, and only rarely has a need to specify a virtual
package (these are in fact all listed in the policy documentation, such as
mail-transport-agent, remote-shell, ... and the required semantics), except
when used among cooperating (usually same-source) packages.

> The only thing .. 

  Without going into detail, some of the significant differences between
.deb/.rpm and rpm/dpkg that impact on an apt-like tool to properly order
installation:

Distinction between unpacked and configured packages
Automatic real package vs. dependency information
Strong ordering of version numbers vs. separate serial numbers
Pre-Dependencies and Conflicts (constrains installation/configuration ordering)
Replacement

And some other issues:
Script failure recovery mechanisms
Config file handling
Build-time dependencies


   Many of these are not covered in maximum RPM, and implementations are not
present in any .spec I've ever looked at.  If rpm can do them, I haven't
seen it.  Many of these exist only for extreme cases, but are among the
reason Debian systems are upgradeable piecemeal, and many rpm based systems
are not.

  Some things .rpm does do better than .deb:

Multiple patches
Embedded signatures
Verification


(on the signatures: Debian may some day embed sigs, but at present they are
in detached files, easing autobuilding without the exposure of secret keys
to automated processes.  The MD5sums of packages are signed in the upload
messages and are in the Packages indices, which are signed by the release
managers on release, and by a not-well-publicized key on other days). 
Source package control files - .dsc - do have signatures.  The binary
signatures are not in the archive, but are available in the debian-*changes
mail archives.)
   
-Drake