Manoj Srivastava wrote:
On Thu, 01 Mar 2007 15:27:02 +0530, Dhawal Doshy said:
In any case, with the upcoming collaboration of redhat, novell, mandriva etc.. i'd prefer rpm over any other packaging format for purely comfort reasons (which also includes laziness).
And the rest of your post descends into matter of preference,as opposed to the technical comparison I have been doing, and is likely to lead into violent opposing expressions of personal preferences of other people on the list.
pronounced guilty.. i accept drifting to OT.. Just to summarize and add some more:
a. RPMs are non-interactive: there are pros and cons for this.. b. The RPM backend database is *very* fragile and the recovery procedure is not too easy c. RPM can be extracted using non-proprietary tools, see: http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch-extra-packaging-tools.h... d. RPMs support deltas (which makes downloading updates much lighter on bandwidth) e. RPMs packages can be signed using sha1 in addition to md5, pgp/gpg f. A source RPM (OR tgz/bzip2.gz + SPEC file) can be used to build multi-arch packages on a single arch (if you have the development tools available). For instance: i do not need a x86_64 machine to build x86_64 specific RPMs and can do it on a i386 machine. g. RPM supports advanced package queries: for instance 'rpm -q --changelog installed_rpm' will actually show the changelog for the spec file. h. RPM supports rudimentary database management utilities, which is not necessarily a good thing always. Further management requires knowledge of berkeley db. i. RPMs can be relocated during installation.. so i could ask rpm to install the httpd rpm in /usr/local/ j. RPMs can be made extensible (though not infinitely) by using macros in reference to the 'new section' part of the URL you posted k. No repository integration with RPM and hence the lack of recommendations and suggestions, but wrapper/front-end tools like yum/apt can overcome this.
That is all i can add at this point..
- dhawal