Debian mirrors and sources.list selections

[David Gibson]

On Thu, Jul 04, 2002 at 05:23:52PM +1000, Drake Diedrich wrote:
> 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, ...).

Well, even easier then.

> > 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.

Yes, that's true at least in part.  Most of the cases where Debian
uses "or" dependencies are backwards compatibility stuff for when a
virtual package didn't exist (as in "exim | sendmila |
mail-transport-agent").  In a number of ways I actually prefer the rpm
way of using virtual packages for shared library dependencies and
script interpreters although it can cause some problems (most of which
would be greatly mitigated by apt-rpm).

That's irrelevant though - apt can handle virtual packages in any
case.

> > 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

Yes, that could cause some problems.  I don't remember enough about
this to be sure.  If it was really bad apt-rpm could work around it by
installing with "--noscripts" then running the install scripts
directly.  The problem is also less severe than it might first appear
because the builtin setup of RPM and Red Hat's (mostly unwritten)
policy means that most RPMs in Red Hat don't need or have install
scripts.  In Debian a package really can't get away without them.

> Automatic real package vs. dependency information

I don't see what you mean by that.

> Strong ordering of version numbers vs. separate serial numbers

rpm has (optional) serial numbering, I don't remember the details, but
I think it's more-or-less functionally equivalent to dpkg's.

> Pre-Dependencies and Conflicts (constrains
installation/configuration ordering)

rpm has conflicts and pre-depends (called PreReqs IIRC).

> Replacement

Got that too (Obsoletes is the tag IIRC).

> And some other issues:
> Script failure recovery mechanisms

That's tied up with the distinctiion between unpacked and configured
packages.  Don't remember enough Red Hat to comment cogently.  Again
the fact that less packages have scripts and the scripts tend to be
slightly simpler helps with this.

> Config file handling

Not sure what specifically you're referring to.  Config files are
generally marker as such (or should be) in the .spec.

> Build-time dependencies

RPM's got them too, in sufficiently recent version.  They don't and
can't work as well as Debian's (which themselves leave a bit to be
desired IMO), because there are multiple RPM distros making it unclear
quite what the dependencies should be.  But in any case apt clearly
doesn't need built dependencies to operate.

>    Many of these are not covered in maximum RPM, and implementations are not

Last I checked, Maximum RPM was *really* out of date.

> 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

I don't think you've looked hard enough.

> are among the reason Debian systems are upgradeable piecemeal, and
> many rpm based systems are not.

Well, yes and no.  I'll grant you piecemeal upgrade does tend to be
easier and more reliable on Debian than with Red Hat, but it's by no
means impossible.  And apt-rpm would make the situation on Red Hat
vastly better.

It does depend on the rpms having the dependency information set
properly (just as it does in Debian).  Red Hat's rpms are usually
fairly good in that respect.  Random third party ("contrib") ones vary
between good and terrible, although when I last looked at them (which
was a while ago) the average standard seemed to be significantly
better than when I first looked at them.  I don't know about the other
major RPM distributors (SuSE, Mandrake, Connectiva etc.).  Linuxppc
were terrible (gross FHS violations etc.) on the RPMS they didn't take
straight from Red Hat .

>   Some things .rpm does do better than .deb:
> 
> Multiple patches
> Embedded signatures
> Verification

Yes, as a Red Hat to Debian convert, "rpm -V" is probably the thing I
miss most (but certainly not enough to make me go back).  Also Red Hat
is more thorough about including all files related to a package,
including config files, logs, lock files etc.  That means it's easier
to find "leftover" files which shouldn't be there (belong to some old,
removed package).  i.e. nearly all files in the "system" directories
(i.e. not home directories, server file areas etc.) will be in the RPM
database whereas in Debian, dpkg -S will not find a package for a lot
of the the (legitimate) contents of /etc and /var (apt-get install
cruft and run it and you'll see what I mean).

-- 
David Gibson			| For every complex problem there is a
david at gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson