apt vs urpmi

[Panu Matilainen]

On Wed, 2006-05-03 at 11:12 -0600, Vincent Danen wrote:
> * Panu Matilainen <pmatilai at laiskiainen.org> [2006-05-03 19:43:43 +0300]:
> > Apt's media / repository handling sucks rocks really :) Some of it boils
> > down to the sources.list format and the library for handling even that
> > is basically non-existent, libapt-pkg only knows how to read the
> > sources, nothing about editing it. Doing something about that is on the
> > roadmap long-term items, the problem is that it's going to be painful
> > wrt anything built on top of apt. For example Synaptic has it's own code
> > to read + write sources.list entries, largely due to the shortcomings of
> > libapt-pkg in that area.
> 
> But this could easily enough be written in something like a shell
> script; it doesn't need to be something apt itself.  I mean, if you
> think about it, urpmi does all the heavy lefting of rpm installation,
> but urpmi.addmedia and urpmi.removemedia do the media management.  True,
> with urpmi you can tell it to disregard certain media (with the urpmi
> --media foo option), which would be nice to see in apt, but the actual
> adding/removing media could probably be done easy enough in a shell
> script.

To some extent you can play with shell wrappers to work around
things ... but it wont fly very far, been there done that. Yum's
--enablerepo/--disablerepo feature is in practise the only reason I use
it these days for anything. Some of that can be achieved with native apt
repositories and pinning but that way lies madness :)

> > > Annvix is meant to be fast and light.  And, if I understand correctly,
> > > it handles GPG signatures now (I think when I first looked at apt-rpm
> > > a few years ago it didn't).  That is the other thing that makes apt
> > > viable for me.
> > 
> > GPG support isn't integrated in apt but can be easily done with
> > Lua-extensions, there are gpg-checker and gpg-autoimporter extensions
> > included in the contrib directory of the apt tarball for example.
> > Integrating the GPG handling again is something I'd like to do in the
> > future.
> 
> Ummm...  hmm.  I thought I saw support for gpg keys in the media
> settings.  What is the point of that then?  Does apt not check if a
> package has a proper key before doing the install?

Apt itself has no understanding of package signatures currently, yet
another thing that originates from Debian - they've only had repository
level checksums until "recently" (I don't follow what Debian does that
closely so I could be off by large margin)

> If not, that seriously lessens the viability of apt for me...  Annvix's
> #1 priority is security, and integrity of rpm packages is absolutely
> important.
> I'll have to look at these extensions to see if they'll do what is
> needed.  If I can't make apt use keys and verify packages before
> installation, I can't use it.

That's exactly what the extension does - optionally automatically import
preconfigured signatures and verify packages before installation, abort
if anything doesn't match or is unsigned (unless overridden with an
option).

> 
> > > > There are more than a few distributions that have interest in keeping 
> > > > Apt-RPM continuing with development, as the other options are just NOT
> > > > an
> > > > option due to speed and
> > > > performance issues, and as noted the added dependancies that they
> > > > bring   
> > > > with them.
> > > 
> > > I'm glad to hear that there is interest in ongoing development.  I don't
> > > want to ditch urpmi just to pick up something that may be gone in a year
> > > or two and force me to go back to urpmi.
> > > 
> > > And if apt has a good focus on security, then I'm even happier.
> > 
> > <cough> Security... <cough> I wouldn't count on that too much at the
> > moment, apt's codebase is *dirty* but the intent is certainly to clean
> > it up + make it safer.
> 
> Hmmm....  well, I guess one way around that is to make apt only
> executable by root (or via sudo).  Normal rpm queries, etc. can still be
> done by a normal user, but install/uninstall/everything-else via apt
> will have to be root-restricted then.

Well, I'm not aware of any reported apt-related security issues, but
certainly you do NOT want to make it suid root :) Not that I'd make any
package installer suid root - you need to fully trust people doing
install/remove/upgrade operations for many other reasons as well.

What I'm referring to as "dirty" is that apt is a rather old piece of
software, it hasn't been updated up to current coding standards, never
mind "security best practises". OTOH like said, I'm not aware of any
security issues reported wrt apt (Debian or -rpm) but that doesn't mean
it's exactly "coded with security in mind" :)

	- Panu -