Hopefully I've helped settle a few minds with this post to meego-dev.
After a lot (and boy, do I mean a lot) of reading, writing, and
discussing the RPMvsDEB scenario ad nauseum, and a more recent
discussion, I thought it might be good to put some positive energy
into the discussion, so here goes.
I'm sorry to add yet more fuel to this fire, but hopefully this will
help douse the flames, rather than raise them higher.
RPM - Why?
Full disclaimer - I am not a packaging expert, but am writing this to
try summarise what I know for the benefit of the community as a whole
so that we can all channel the energy that has been devoted into this
issue into something more productive and exciting.
I would welcome any commentry on this. Should it be seen as suitable,
perhaps it might be an idea to put something similar to this up as an
FAQ item, as this certainly has been asked frequently.
A lot of discussion and questions have arisen over the past few days
through the Maemo and Moblin merge into MeeGo, with a lot of it
centering around one particular issue: that of RPM vs DEB packaging.
The current state of things is as such - Moblin uses RPM, Maemo uses
DEB - but this issue is not as simple as a packaging format, it's an
entire toolset. I'd also like to very quickly and emphathetically note
that this is purely addressing RPM and DEB, not Fedora and Debian, or
yum vs apt-get, or anything like that.
Maemo's toolset, in the form of scratchbox, sbmock, autobuilder and
co) has a number of kinks which have caused all sorts of fun issues,
but at the end of the day, have worked.
Moblin's toolset has equivilents to do package building - but then, a
lot more, which is not currently available for Maemo. There are
various other tools which are needed to further aid development, such
as the image creator
With this in mind, it is clear that Moblin's toolset has a number of
more capabilities to add that will infinitely benefit development and
QA, which is definitely an advantage to MeeGo, unfortunately, some
elements within this chain do not work with RPM.
It may of course be theoretically possible to rework these tools to
work with a different format (or multiple formats), but let us take a
step back and consider how pragmatic a decision that is, when at the
end of the day, we are talking about a format - both of which bear a
lot in common.
While possible, perhaps - just perhaps - there are other more
important priorities to focus on, and a bigger picture - above the
religious warfare - to keep in mind: that while we have gained RPM, we
have also gained organisation, a solid process and great tools built
to engage the wider community.