Re: RPM (Was Re: Deity project schedule problems)
> OTOH, the package format is more cryptic than debs, and less powerful,
> and that is the main problem involved. If we switch to RPM, we loss
> some power and a lot of time (it's a hard work to go there), to be
> able to use their tools (no point in doing a better RPM if others won't
> adopt it) but, do we gain that much using those tools, that can not be
> easily added to our current ones?
Like I've mentioned, there is mechanism for adding new features
through the RPM Foundation. It will cost time to convert; other than
conflicts/replaces, I haven't actually found any missing *features* of
the "protocol" (the format is, after all, under the abstraction of the
program, just like .deb format is...) I'd like to hear about it, if
anyone else can name some, just to get an idea of how much work it
would *actually* be. Adding these kinds of features seems to be the
point of the RPM Foundation, though -- so others *can* use these
new features eventually.
> Uh? These are late news for me. I've always thought it was a lot
> more rigid than our rules+scripts approach. I should go again reading
It's more like "scripts without rules" :-) A specs file has some
organization of sections, pre and post install/rm sections, all sorts
of stuff glommed into one place. There's a fair parallel between the
debian *directory* and the specs file...
As I mentioned before, my experience with rpm is all recent, from
having to build sgml tools for coworkers. It took less work to set up
an rpm package; as counterpoint, it's also easier to do a bad job and
still end up with a package -- debian's package construction
complexity is enough to keep people from making progress when they
don't quite get it yet :-)
--
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: