Hi Manoj, I am not sure what brought about this comparison.... so will refrain from being overly verbose..
Manoj Srivastava wrote: > Hi, > > It might be instructive to compare package file formats on a > purely technical level: http://kitenet.net/~joey/pkg-comp/ > This is a fairly authoritative document, and well worth understanding. good read indeed. > > Here follows commentary on the major points of difference oj > just the rpm and deb format (please read the URL for details > regarding other package formats). > > 1) Data unpack-able by standard tools, meta-data accessible by > standard tools, and ability to create a .deb with standard (non > distribution specific) tools: .debs are just ar archives of > tar-balls, and can be unpackaged, inspected, and created using cp, > chmod, ar and tar. rpm's need a special tool. Now, why is this > important at all? Well, think of a classified environment, where > you do not want to rely on the packaged tool to help you with > forensics; but you have a trusted solaris box. rpm's are cpio achieves, its easy to yank the payload out ( but yes, much of the metadata and header-non-payload is lost ). > > 2) Package relationships: The .deb format has a more nuanced set of > relationships, incorporating recommendations and suggested > packages, and orders packages by priority as well as group. hinting by way of suggests and enhances are available in rpm, just not widely used. PLD ( iirc ) were the first guys to start deploying enmass such functionality. > Personally, I am of the opinion that file dependencies are a mixed > bag; they complicate the package dependency graph with edges that > are different from a package dependency; added to the less > nuanced dependency and priority information, they make the > installation ordering of rpm's far less sophisticated. while not directly related to your statement ... rpm does have the ability to ( if the user so wants, I've not seen this deployed in a package management system as yet ) include perl / python / ruby deps directly as well. So if a rpm package wants a certain perl-module to exist, rpm can check for the existence of that perl-module even if its not mentioned in the package metadata manifest for the machine. so given that pretty much every language devloper ( and his dog ) are trying to come up with means of sub-language-functionality-delivery ( php-pear, perl-cpan, ruby-gem etc etc ), a smart way to handle some part of this and overlap this info (?) with the system package metadata manifest is going to be important issue to work on, for any packaging system. > order, and rolling back failed installation. rpm does > installations on a best effort basis, and thus failures at > critical stages leave the system in an untenable state. while this is true, its important to note that a proper package management / repo management system on top of rpm like yum or smartpm or apt-rpm should only hand down package sets in a single transaction. If that happens, rpm wont break anything - problems are reported quite loud and clear, except for when there is a deploop that needs a break ( when the best effort basis kicks in, and package ordering for with the deploop becomes hard ). > 4) Debian packages may run binaries at install and un-install times. > I am not sure if this is a major plus. is this like the %pre , %post, %preun and %postun scripts in a rpm ? > 6) New sections in the package format: .debs were designed to be > extensible, and whole new sections can be added to the package by > adding yet another tar-ball or the ar archive. Some of the future > additions being planned are detached signatures by various keys; > developers key, build daemon maintainer key, archive maintainers > key, release manager key, mirror master key, -- in a new section > of the package file. So, new data sections, compiled binaries > for more than one sub-arch, or 32 and 64 bit binaries -- they can > be added easily to a new section, and dpkg be told how to deal > with the new sections by inspecting the .deb format version. > > rpm's can't as easily cope with unseen new requirements. I dont quite understand what this implies ( perhaps a use-case-scenario will make it easier to parse ). The ability to add user defined metadata into a rpm header-not-payload is under development - I've seen it being used, but mostly off -devel trees, not in any released rpm used in a distro. btw, I also rate the ability of rpms to handle multilib and arch specific packages to be a big plus. -- Karanbir Singh : http://www.karan.org/ : [EMAIL PROTECTED] _______________________________________________ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
