On Fri, 02 Mar 2007 02:36:14 +0000, 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 -- [email protected]
http://frodo.hserus.net/mailman/listinfo/ilugd
Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi
http://www.mail-archive.com/[email protected]/
