Re: [ilugd] deb vs. rpm
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/
Re: [ilugd] deb vs. rpm
On Fri, 02 Mar 2007 02:36:14 +, Karanbir Singh said: 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 ). Well. It also means the scripts run can not be easily accessed using standard POSIX tools -- since they live in the metadata that is lost. 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 ? yes. But since they must live in a spec file, they are restricted to being scripts. If I want some binary to be executed at the preinstall phase (before the rest of the data segment has been unpacked, or in the postrm stage (where most of the package is gone), and these binaries do not exist on the target system, I can do so with a .deb package format, since the maintainer scripts are external files, and can be statically linked binaries. As I said, this is not a huge win. But it is a difference. 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. Ok. Currently a .deb has two segments -- a DEBIAN segment, that contains the metadata, and maintainer scripts, and a data tarball that is extracted on to the file system. rpm's have a similar structure -- but the meta data bit is hard coded format concatenated to a cpio format for the data. If I wanted to add detached signatures from some certifing authority -- I can have, say: a) DEBIAN.tar b) data.tar.gz *c) dev-sig.asc *d) archive-sig.asc *e) mirror-sig.asc Since we just have an ar of other parts, the nbumber of segments added on can be flexible -- and older dpkg can still handle the .deb file, by ignoring the new segments. Newver versions of dpkg can note the missing new segments, and deal with it according to whatever policy is in effect. btw, I also rate the ability of rpms to handle multilib and arch specific packages to be a big plus. Debian does have arch specific packages -- and there is work going on on multi-arch, to allow mixing of 32bit and 64bit packages on the same box. manoj -- In a medium in which a News Piece takes a minute and an In-Depth Piece takes two minutes, the Simple will drive out the Complex. -- Frank Mankiewicz Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ 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/
Re: [ilugd] deb vs. rpm
Manoj Srivastava [EMAIL PROTECTED] writes: 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. Well, these relationships are defined by the individual(s) who create the package(s). How does the package format help here? 4) Debian packages may run binaries at install and un-install times. I am not sure if this is a major plus. Did you mean scripts? 5) Package verification and triggers -- rpm has them, and package verification is one of the major features missing in a .deb. triggers, well, there is a technical proposal currently being debated about adding triggers to dpkg, but obviously, Debian is playing catch-up here. What about debsums? I remember seeing a discussion about this is some recent (previous 2 weeks) in some mailing list. That said, does this mail have anything to do with ESR's desertion of RH/Fedora ? (grin) -- Mahesh T. Pai http://paivakil.blogspot.com/ Learn from the mistakes of others. You won't live long enough to make all of them yourself. ___ 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/
[ilugd] deb vs. rpm
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. 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. 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. rpm does not have the nuanced relationship, nor priority, but it does have file based dependencies, and easily extract-able copyright information so it is easier to marshal packages by copyright info. 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. dpkg goes through a song and dance ordering packages with topological sorting of the graph, breaking installation into chunks to ensure that no conflicting packages ever are unpacked at the same time, unpacking and configuring packages in dependency 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. 3) rpm can mark documentation files (makes it easier to find docs), and has ghost files, files which are not shipped in the package but are registered as being owned by the package. For documentation, Debian relies on convention; all package documentation is found in /usr/share/doc/$package; but ghost files are clearly a plus for rpms. 4) Debian packages may run binaries at install and un-install times. I am not sure if this is a major plus. 5) Package verification and triggers -- rpm has them, and package verification is one of the major features missing in a .deb. triggers, well, there is a technical proposal currently being debated about adding triggers to dpkg, but obviously, Debian is playing catch-up here. 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. manoj -- You will have a long and boring life. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ 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/
Re: [ilugd] deb vs. rpm
On Wed, 28 Feb 2007 23:12:06 +0530, Mahesh T Pai said: Manoj Srivastava [EMAIL PROTECTED] writes: 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. Well, these relationships are defined by the individual(s) who create the package(s). How does the package format help here? You can't define relationship types if the package format does not allow them. For example, if I wanted to say that this package depends on the other package in the winter months, I can't do that in the debian control file :) 4) Debian packages may run binaries at install and un-install times. I am not sure if this is a major plus. Did you mean scripts? Yup. Since maintainer scripts have to live in the spec file, they must be scripts -- for Debian, since they are in external files, you can sneak in binary maintainer scripts -- you would violate Debian policy, but the .deb format allows that. 5) Package verification and triggers -- rpm has them, and package verification is one of the major features missing in a .deb. triggers, well, there is a technical proposal currently being debated about adding triggers to dpkg, but obviously, Debian is playing catch-up here. What about debsums? I remember seeing a discussion about this is some recent (previous 2 weeks) in some mailing list. debsums are not mandatory in Debian, so some packages do not have them. Sure, you can attach debsums to apt hooks, but then that does not work dor a dpkg -i foo.deb. Ideally, it should be in dpkg, so that after the postinst is run, with debconf and all, hashes of configuration files in /etc are calculated. This might happen now we are talking about dpkg triggers. debsums does not handle modified configuration files. That said, does this mail have anything to do with ESR's desertion of RH/Fedora ? (grin) No, except I feel sorry for Ubuntu. manoj -- Govern a great nation as you would cook a small fish. Don't overdo it. Lao Tsu Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ 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/
