At 2007-01-11T22:53:27+1300, Volker Kuhlmann wrote:
> And I reserver judgement on the "pristine" for later, because some time
> back it was always debianjumble.tar.gz.
As far back as Debian Buzz (1.1, mid 1996) and probably earlier, the source
has been provided as a pristine tarball and a patch file. The description
file came later.
> With rpm that has been required policy from day 1, and well over a decade
This has little to do with the tool itself, it's a distribution and package
maintainer policy. Debian has had the same policy for a very long time.
Both of the tools provide a method for building a source tree from a
pristine tarball plus a patch set. The Debian tools also make it easy to
generate the pristine tarball and patch set from a modified source tree when
you're acting as the package maintainer--I don't know about the RPM tools,
but I expect they provide something similar.
> If it doesn't matter then why not have several binary debs as well? One
> for /usr, one for /etc, ... If one has a packaging system, then 1 file
> ought to do for it. Or why have a "package"?
Because the contents of a binary package strictly depend on the rest of the
contents of the binary package--the stuff in /bin is useless without the
requisite bits from /usr/lib.
At least two of the components of the source 'package' are independently
useful. The pristine tarball is useful if you want the pristine source.
The patch file is useful if you want to review or pick up the
Debian-specific changes if you're a maintainer for another distribution or
whatever.
Debian's way of doing things is useful for people without dpkg and the rest
of the tools--there are no special tools required to get at and use the
components of the source package.
This is also true for the binary packages. A deb file is just an ar(1)
format archive that contains a control (install scripts) and data (actual
binaries, etc.) tarball.
> On a Debian system, yes. Otherwise, no, and it's pasting some URLs
> (plural) into wget.
Not much different from an SRPM, it's just 3 vs 1 URLs. If you're
downloading lots of source packages on a non-Debian system, write a script,
then the number of components is even more irrelevant.
Say you want to build gzip 1.35-15, you grab: gzip_1.3.5-15.dsc,
gzip_1.3.5.diff.gz, and gzip_1.3.5.orig.tar.gz. Note that the dsc file
contains the filenames and checksum of the other two files, so if you want
to be fancy you can grab that first and parse it to get the other filenames.
The dsc file itself has an inline OpenPGP signature of the package
maintainer. Assuming you have established a line of trust to their public
key, this provides you with an assurance of authenticity for all three
files.
Additionally, debian.org has a nice search interface where you can look up a
package and it provides the URLs for the binary packages for each
architecture and the source package pieces.
I find it's a lot more effort to dig up the SRPM for a particular package
for, say, RHEL, than it is for a Debian release.
> Well over a decade behind rpm... but it's good to see dpkg catching up.
I should clarify. The package formats have had checksum verification since
inception. This takes care of detecting corruption during downloads or
shipping packages around on physical media.
What I talking about (as a new thing for Debian Etch) is the "secure apt"
project. This means that apt will verify the OpenPGP signatures of packages
(which have been signed by the maintainer for a long time--the signature is
required to upload a package) and the Release files (which are signed by the
release masters) to provide a degree of confidence that the packages were
built by who they claim they were built by and provided via the official
distribution mechanisms, and have not been tampered with.
> Sorry, my considered opinion. I remember when the Megabyte to download
> cost $5.00 (special uni rate, 3x that from commercial ISPs). Crypto-signed
> packages were a godsend!
Having a checksum or an OpenPGP signature along with a package corrupted
during download isn't going to save you from having to download it again at
$5/MB. When this happens, what you really want is the ability to use rsync.
> Ok, will add to package list. Does it do permissions, ownerships and the
> works too?
No, just per-file checksum verification. This is certainly a bit of a weak
point. There are, perhaps, arguments that this task is better left to a
dedicated tool such as tripwire.
> Bottom line is still that I can't see anything dpkg does better than rpm,
> but a few things where it doesn't match. At least one of them important.
Well, it's not like you're really trying to see where the Debian tools are
better.
All of the packaging systems have their own strengths and weaknesses. Right
now, there is no one packaging system to rule them all.
And, hey, I could write a list of stuff I think is wrong with RPM and the
surrounding support utilities, but what would be the point?
(On that note, it's nice to see the multi-year infighting over who really
maintains RPM is starting to wrap up... there's actually somewhere to send
patches now! Oops, I did let one complaint slip out.)
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
