Tuesday, 16 February 2010

Meego - RPM vs DEB debate.

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
(http://moblin.org/documentation/moblin-image-creator-2/using-moblin-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.

18 comments:

Gaveen said...

I've always been a FOSS promoter but I'm new to these (i.e Maemo, Moblin & MeeGo) communities. But I'm super excited about MeeGo and willing to contribute as much as I can. Recently I even started learning to work with Maemo 5 SDK because I'm that excited.

My point is, I found the (RPM Vs Deb) discussion too much into religious fanboyism and fallacies that I had to temporarily turn off mail updates from meego-dev. :) I believe the community will gradually fall into place when actual work gets going and community leadership becomes apparent. But for now keeping rationality in check is much needed. So, thanks for writing this.

Looking forward to an exciting future for the project. As you said: "...while we have gained RPM, we
have also gained organisation, a solid process and great tools built to engage the wider community."

Aigars Mahinovs said...

Well, Maemo never used the DEB to even a quarter of its potential. It was as simple as setting up a devel-universe repository where all packages from Debian would be available recompiled for Maemo.

The way has been shown by Ubuntu years ago - take Debian, make snapshots from it, recompile, polish, add you own UI and customisations and here you have it - the best possible Linux.

Refusing DEB is also refusing the apt-get, the cdbs, the debhelper and all the software that is ready to go and prepackaged in the Debian repositories with all due reverence to FHS and Debian Policy. Man-milleniums of work are just there for taking, but Nokia decides to trow it all out and start over from scratch. RPM is miniscule compared to DEB.

Robin Burchell said...

@Aigars: while I appreciate your point of view perfectly well, nobody is throwing anything out here -- as I said, if community consensus is there to use DPKG, and there are people willing to write the code, we can make it happen together.

This is our playground now, we don't want or need to wait for Intel or Nokia to hold our hands.

Robin Burchell said...

@Gaveen: indeed! it's a very exciting time to be involved here, and I'm so happy that I got involved when I did.

I'd suggest reading up on MADDE and Qt (and Qt Creator) as I believe these are going to be the way forwards for the SW stack on MeeGo.

Ben Lau said...

In fact , the original Moblin Image Creator v1 work with Ubuntu, but they have dropped the support of v1 and ship to v2 which is totally different than v1. And V2 is RPM only.

From my point of view , MIC v1 is much more powerful than v2, it has simplifed the build and customization process.

Robin Burchell said...

Hi Ben,

Admittedly, this was only an example. There are other tools, and other parts of the process.

It would be nice if DEB support could be maintained, for obvious reasons, but if it isn't going to be used, it's going to rot, and while I wasn't involved in the removal, that would be my best guess.

Again - it's up to the community members who are interested to step up to this and get the ball rolling. :)

Samael Wang said...

"Moblin's toolset has equivilents to do package building - but then, a
lot more, which is not currently available for Maemo."

Quite interesting. I tried moblin image creator when I was an intern in Intel. I thought the most weak part of moblin IS the development tool.

Moblin has never provide a highly integrated and easy to use development tool as maemo provided for years.

Samael Wang said...

Further, if it was not a job, I wouldn't even try to use it. Has Intel EVER successfully build Moblin community?

D. Moonfire said...

In general, I'm not a zealot about the package format. Sooner or later, they all get the best features of the other one. I happen to prefer DEB files over RPM, but that is because of history. I've had a few servers that were moderately updated (i.e. behing a firewall and used internally) using RPM-based distributions (RedHat, Mandrake). Since they were shielded, I didn't quite update them as often as most people and I got nailed when the RPM format changed on me and I couldn't easily get the machine upgraded. I had the same problem with Gentoo, actually, but I never did with Debian servers. So, I find myself preferring Debian simply because I know if I don't update a machine for six months (or two years *cough*) I can still do an `apt-get update;apt-get dist-upgrade` and it will mostly work.

I haven't really paid attention to RPM's metadata format since I moved to Debian-based systems, but I do really like the metadata structure for Debians. `apt-get` is a beautiful thing, but also the amount of structure they have on bugs.debian.org, the repositories, and infrastructure is nice. Again, RPM probably has that these days, but I don't remember it being quite so organized when I was involved with RPM's.

Robin Burchell said...

@Samael: If you're really implying that Scratchbox is superior to tools like OBS, then I wonder how deep into Scratchbox you got. It's not really pleasant.

MIC itself might not be fantastic, but it is one example of the many good tools and infra that Moblin has integrated into their process.

Aldon Hynes said...

It seems like a lot of the DEB v RPM fanboy discussion is based on either-or thinking; either we use DEB or we use RPM.

I've been using DEB for a while on my N900 as well as various Ubuntu devices that I have. I like DEB. However, the little I've seen of RPM also looks nice.

However, I don't buy that it has to be either-or. I've set up my N900 to use a Fedora-ARM RPM program along side the default DEB system that the N900 uses. It is still a bit kludgy, but it works and gives me more choices.

I started looking at apt-rpm which allows apt to install rpm files. Someone pointed out that I'm better off looking at smartpm, which I've now also installed on my N900 and it looks really nice. It can install both DEB and RPM. (Standard caveats apply about being careful about not mixing packages and clobbering one another.)

Also, according to some discussions on the mailing lists, OBS can generate both DEB and RPM files.

So, I just don't buy the either-or thinking.

(For more thoughts on this check Maemo, Moblin, MeeGo, and running RPMs on the #N900)

Lee said...
This post has been removed by a blog administrator.
Owais Lone said...

Meego is awesome.
The direct enemy is the iPad.
iPad has only one but BIG advantage, that is the app-market. How can Meego compete with that?

The Answer:
Ubuntu are doing awesome work to attract thr iPad-like developers to write apps for Ubuntu. With quickly, writing an Ubuntu app is probably the easiest kind of programming around and this is only the beginning.

Meego will have to switch to Ubuntu's packaging + Quickly if it even want to think about competing in the tablet market.

A.T. said...

I'm afraid you all see it only in technical perspective, while reality had been slightly different... decision making had been done mostly on political level between Nokia and Intel, and it is all about "whose *community* past time & effort will be thrown under the bus?" - and the very first answer (with RPM choice made in very beginning) tells a lot about it.

Robin Burchell said...

@A.T.

I kept my views strictly technical, as that's where the arguments were happening, and, as far as I was concerned - most of those arguments didn't have basis, and for those that did they seem to not be *that* important after all. At least, that's what I would surmise, as there still seems to be no concerted effort to do anything else. (A working group was proposed to repackage stuff, but I've yet to hear anything other than "we're going to do it" out of that effort)

As for the rest of your point, really, I think we'll just have to agree to disagree.

My (subjective, obviously) opinion:

At the end of the day, I don't care which system is used, because they're both fairly equally capable, and packaging is not a matter of life and death. It should not (and is not) an overly complicated process. If people are completely put off the idea of a completely open OS for consumer devices by something as minor as a packaging format, then I suggest that their attitude needs a little bit of adjustment.

At the end of the day, yes, things still aren't the perfect utopia with MeeGo (yet), it was bootstrapped, and is facing the prospect of code dumps (handset UX), but it is (as far as I am concerned) the best imperfect option amongst a sea of imperfection.

I won't *quite* say that the ends justify the means, but at the end of the day, if a little political compromise in some places leads to a nice set of deals being made that leads to a more competitive OS than would have existed otherwise, then I'd call that acceptable losses.

(And so far, that's pretty much what has been happening[1], which is quite good going given that there still isn't actually a device running MeeGo out.)

[1]: http://www.google.com/trends/viz?q=meego,maemo,moblin&date=ytd&geo=all&graph=weekly_img&sort=0&sa=N

chrism said...

Hmm... I'm a developer. I'm using Linux since 1992 (kernel version 0.95). I've used RPM for years, and one day I started to use DEB, and meny of its benefits.

This is my personal opinion, but if you're using DEB, there's no way back to RPM.

jclark5093 said...

I have to learn RPM for cert exams, and I have found (after years of using Debian and Debian based systems) that learning RPM and YUM is *not* fun. I know that learning something new is not an exciting prospect when it comes to something like maintenance (i.e. package handling), but my real problem lies in that it seems that Aptitude and .Debs are just faster and more reliable. (Of course this is based on my personal experiences.)

Maybe that's depending on my repos, or bad programming by RH (and subsequent foss based systems), or maybe RPM just has a personal thing against me; I don't know.

All I know is that once I learn RPM and YUM, I will remove whichever OS I can find to learn it on, and never look back. I'd rather compile from source than use RPMs (something else that I've never done, but comparing the prospect of the idea, while time consuming, it seems that it would be much safer.)

But, again, this is just based on my experience, and not expertise.

Ben Lau said...

Moreover , beside the debate of RPM vs Deb, it should also need to consider to use a format other than them.

I am a N900 user. The App Manager (a frontend to Deb) is extremely slow. It take a long time to load package list and install new software.

I am not blaming deb , I believe rpm will have the same problem on a slow device (in compare to Desktop).

On mobile device , it is non-sense that I need to load a super long package list in order to install a tiny application.

I think that deb and rpm should be used for core system only. And mobile application software could use another package system which can be self-contained (just like what Android and iPhone does) . So that the installation can be much simplified.

I found an extreme project called AppImages. It can make a DMG-like software package on Mac. Will be great if it can add tiny dependence information (e.g What CPU architecture and device).

http://www.elementary-project.com/wiki/index.php?title=AppImages

Post a Comment