apt vs urpmi

[Gary Greene]

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

Agreed on both counts. These are the main issues being looked at by
libapt-front being developed by Peter Rockai from RedHat and a few
developers from other distributions, in particular Debian.

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

I've used apt-rpm on SuSE and they did do what you want, though I'd
personally like to extend the scripts a little more since they currently
do a all or nothing method of handling, such that if ANY of the packages
are unsigned, they will not be installed at all, without any intervention
from the administrator.

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

This seems to be reasonable to me, as the aspect of adding and removing
software should only be done via a trusted account.

> --
> 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...
> _______________________________________________
> apt-rpm mailing list
> apt-rpm at lists.laiskiainen.org
> http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org
>