Re: RPM (Was Re: Deity project schedule problems)
Your sentiment is reasonable, your evidence is weak...
For example:
>Some examples of packages that we've developed that probably would never
>have happened if we used RPM:
> dpkg-ftp, dpkg-mountable, dpkg-cert, dpkg-perl, dpkg-python,
> debmake, debhelper, alien, dftp, dpkg-repack, dpkg-cross, menu,
> fakeroot, suidmanager, cvs-buildpackage, kernel-package
rpm includes dpkg-ftp as base functionality (package names are url's :-)
dpkg-cert, if I understand it, is rpm --verify. alien is meaningless
when the formats are the same. dpkg-perl: I think there *are* rpm::
modules in CPAN. as for fakeroot: rpm handles it by letting normal
users build, and then having a "cleanup permissions" stage at install
time; crude, but effective, and done a *long* time ago. dpkg-repack
doesn't seem to have an equivalent (though I've never had a *good*
reason to use it, only some bad ones) and suidmanager is debatable as
well, *especially* without things like rpm --setperms, which actually
lets you make the installed permissions match the package...
So, sure they wouldn't have happenned -- because rpm *already* handles
them. Of course I don't know the history here -- but *do* try to be
more aware of what rpm is actually capable of, and argue *that*.
As for the "control from above" model, I'm not convinced it's still
there. Of course incompatible changes are unlikely to be accepted in
rpm, but that's just good software engineering, and as I pointed out,
I think the specs file is *more* flexible than anything in
debian... *too much* more flexible, if anything, and not *enough*
structure. Skim through Maximum RPM to get some idea (but not to
argue limits -- there's been lots of stuff added to rpm since the book
came out.)
> We're limited more by the policies we choose than by any
> technical limitations.
*That* I can heartily agree with.
> (more innovation-oriented -- less product-oriented),
That's less clear. Certainly my drive as far as X releases goes is to
put out a solid *product*, namely the 2.0 release (for now.)
Committing to actually support libc5 development on a libc6 system is
an interesting challenge, for me at least... and the reason I took
over emacs packaging in the first place is I wanted a solid and up to
date build :-)
_Mark_ <eichin@kitten.gen.ma.us>
The Herd of Kittens
Debian X Maintainer
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: