apt vs urpmi

Vincent Danen vdanen at annvix.org
Wed May 3 10:12:30 PDT 2006


* Panu Matilainen <pmatilai at laiskiainen.org> [2006-05-03 19:43:43 +0300]:

> > Yeah, I know the commandline will be different which will probably be
> > harder for me than any of my users... =)  I actually work for Mandriva
> > so have been using (and used to) urpmi since the day it was written.
> > But I'm up to the challenge.  I think I'll probably miss (and screw up)
> > the commandline stuff for a while, but it'll get better.  Also, Annvix
> > does a *lot* of stuff different, so even though it was originally based
> > on Mandriva, the entire system has changed to the point it doesn't even
> > resemble Mandriva anymore except for urpmi (things like runit vs
> > sysvinit and other changes).  So "change" isn't necessarily a downside
> > as those of us using Annvix know there is not a single distro out there
> > like it.
> > 
> > Oh, and "average user" isn't a word we use with Annvix... there are no
> > "average users".  =)
> > 
> > As far as the README.urpmi stuff goes, I don't think I've ever really
> > used it.  In Annvix, we use the OpenBSD "man afterboot" approach and
> > build dynamic manpages with information.  What little information needs
> > to be immediately apparent (such as setting up a password for mysql,
> > say) gets sent to STDOUT in the %post scripts.  I think maybe one
> > package has a README.urpmi, so that's not a big issue.
> > 
> > Media filtering could be a bit of an issue, but I don't think it should
> > be bad.  Because of how differently we do things, the "average" Annvix
> > user should have two media: the main annvix medium and the ports medium
> > (the latter is compiled-from-source rpms stored in a local repository on
> > the machine).  The chances of things conflicting there are pretty small.
> > We don't have to worry about main (7 CDs) vs updates vs community vs
> > contribs vs PLF vs all the other urpmi media out there.
> 
> 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.

> > > Also, from an ex-urpmi users standpoint, apt seems to play better with 
> > > speed than urpmi as well due to the fact that it is all in a compiled
> > > language.
> > 
> > Oh absolutely.  I kinda new that apt would likely be faster and, I'm
> > assuming, have a smaller footprint as well.  With every urpmi operation,
> > perl needs to be run which gives us nice overhead.  With apt, there is
> > no overhead, which is good.
> 
> Yup, speed is certainly one of the main attractions about apt compared
> to other alternatives.

I like speed... =)

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

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.

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

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20060503/4321cacb/attachment-0003.pgp>


More information about the Apt-Rpm mailing list