I always wanted to know that: when i download a .deb file, usually it follows the scheme

random_app_v1.00+0m4.deb for OS2008 Diablo / N810
random_app_v1.00+0m5.deb for Maemo 5 Fremantle/ N900
random_app_v1.00+0m6.deb for MeeGo 1.2 Harmattan / N9

But now i see in my N9 apps (mainly coming from Nokia) who ends with 0m7 and 0m8, what does that means? Can someone explain me the naming scheme? it's some kind of mark they give the apps to say is compatible with Meltemi etc (i know it's a killed OS, but only from few days ago, it could explain all the infraestructure they build across the Ovi Suite to mark apps as N9 & Meltemi compatible)

Dont know, and why two different names, 0m7 and 0m8, what's the difference between the two?

It means whoever is handing packaging has no idea what they're doing.

In short, when N9 packages have been recompiled for PR1.1 and PR1.2 they got the suffix m7 and m8.

actually I fear this is a mix between debian convention and nokia ones...

I guess every packages are in X.Y.Z-0mN
N is started with the maemo/meego version ie : X.Y.Z-0m6
once they update it N++ ie X.Y.Z-0m7 ...

They know exactly what they are doing. Let me explain the packaging versioning scheme using as an example a package I maintained.

Speedcrunch is a powerful calculator, part of the KDE project. The latest speedcrunch version when Timo Harkonen, the original maintainer decided to port it to maemo was 0.10

Every time you push a new version to the repositories (devel) you need to bump the version number of your package so that the package managers in peoples' devices know that there is a new version. Everything after the underscore in a package name is considered a version string. During the process of porting, maemo specific bugs or misconfigurations happen (my initial speedcrunch port had a non-working icon because of some difference between hildon and kde) so you have to bump the version string, but still keep the info as to what upstream version you are basing on.

For example let's say that package myServer 2.18 from debian is out and I decide to port it to maemo. I make some trials and errors, and as I have to bump the version each time I push it to devel the resulting package is named myserver_2.24_armel.deb

Then the debian maintainers out a new version of MyServer (2.22) that supports MyPlugin. Installation of MyPlugin depends on myserver >= 2.22. A happy coder sees that there is a version of MyServer for Maemo >= 2.22 and decides to port MyPlugin. Frustrated, he realizes that MyPlugin, whatever he tried doesn't work.

What's wrong with this picture and how to fix it?

The fix is that when you port an existing application or lib from <distro> to Maemo you suffix the name with maemo0 (e.g. myserver_2.18maemo0_armel.deb) and after any maemo specific fixes/changes you do you bump the version number after maemo, resulting in myserver_2.18maemo1_armel.deb etc. This way you keep the info about what features your lib/app has and you keep your dpkg happy too.

The number after maemo has no connection with the maemo version except if the maintainer wanted it so (which is not usually the case) and then it has another digit after that (myserver_2.18maemo5-3_armel.deb or myserver_2.18+m5-3_armel.deb)

Another thing you might notice is that some packages have the major version number right after the name (python2.5) after a dash (qt-components-10_1.0-pre2-1+0m5_armel.deb) or after an underscore (speedcrunch_0.10.1maemo5-1_armel.deb)

The version number taken into consideration by dpkg is the number (or alphanumeric) after the underscore. Any number before the underscore, either after a dash or adjacent to the package name is treated as part of the name. So your application manager (or apt-get) will notify you an upgrade has been found if you have package_0.67_armel.deb and package_0.70_armel.deb appears in the repository, but it will not notify you that an upgrade to python was found if python3.0_armel.deb appears. This was also done deliberately as python 3.0 is incompatible with python 2.5 and any automatic upgrade would break all your python applications. You'll probably want to have both pythons on your device, and this naming scheme allows that.

Short story:
randompackage_0.54-maemo7_armel.deb is not for meltemi, it's just the 7th version of the package for the maemo platform this deb was intented for.

EDIT: I saw the posts between me starting to write this post and posting it, sometimes it is possible that they started with m6 and bumped that instead of adding another digit. If you go here though you'll see many packages for fremantle ending with maemo0, maemo2 etc.

Very nice post, qwazix, but now that most of us are getting the PR1.3 update, how can you explain my phone pops up showing a update for the facebook native client from 1.2.40+0m7 to 1.3.2+0m8? since 1.3.2 > 1.2.40 what's the need to increase 0m7 to 0m8?

There is indeed no apparent reason to do that, but I assume developers got used to the process I described above when maintaining upstream packages and bump the maemo-specific version number when packaging.

Another possibility is that internal processes involve separate roles of coder and packager. 1.2.40 is the version of the code and 8 is just a number that increases each time a new package is made public. This way, small changes done by the packager do not interfere with the bugfixes of the coder, and no coordination is needed between them regarding the version numbering.

A third possibility is that the same codebase is shared between symbian and harmattan and so my previous post applies verbatim.

I thought in that before, but I think this is also made for compatibility purposes. Does anyone tried to install 0m7 / 0m8 packages on PR1.0 / PR 1.1. I heard QML / QtQuick made apps break compatibility on PR1.2 because of new build-in version, is that true? may be is because of this?

I will check if i can install the new 0m8 facebook version without update PR1.3, and once update to new firmware, try to install old version. Will report later.

I just tried updating Nokia Music from 0.3.9-1+0m7 to 0.4.5-1+0m8 without upgrading to PR1.3 and it fails, demanding I 'Update device software'.

In the above examples 1.00 is the upstream version and m4-m8 are distinct Maemo versions based on that release. The number following the m has nothing to do with the underlying OS, it's just a monotonically increasing sub-version number. See http://wiki.maemo.org/Packaging/Guid...n_of_a_package.