[meego-packaging] MeeGo Package Versioning (was Re: MeeGo package SR procedure)

[David Greaves]

On 03/12/10 20:41, Selbak, Rolla N wrote:
>  So to answer your q, you're right, the SR# bug comment is not necessary
> right now, but a nice-to-have for ease of tracking.
>
> The one thing you are required to do is make sure the bug or feature you are
> requesting is set to 'resolved', which indicates that the code is submitted.
> Then once it hits MeeGo Trunk, Release Engineers will set the bug to
> 'released', or if the submisison is rejected, they will set the bug to
> 'reopened'.

I am still concerned that MeeGo cannot easily (historically) determine which rpm 
or release a bug is fixed in. This is especially problematic on a week-to-week 
basis and it matters more to our customers (device vendors) than to MeeGo core 
engineering - which is why
a) it is important
b) we don't really see it - so we don't care

The main problem is as simple as "the changelog doesn't mention the rpm release 
number". Only the upstream source version; and that can stay static for a long time.

[1] is a bug where this caused real problems. Sadly it's a closed vendor bug so 
I've posted snippets at the end:
(If you have access then please take a look at the bug)

As mentioned in that bug the changelog (snippet) is the canonical source of 
information about a package:

# * Wed Oct 13 2010 Markus Lehtonen <markus.lehtonen at nokia.com> - 0.61.25
# - Fix BMC#8330 by modifying dbus.conf
#
# * Fri Oct 01 2010 Markus Lehtonen <markus.lehtonen at nokia.com> - 0.61.25
# - Version bump to 0.61.25
# - Bugfixes plus some of the previous MeeGo-patches now merged upstream

When I check, what rpm contains the fix?
Answer: 0.61.25-2.1 in release W43 and not 0.61.25-1.1 in W42

So I'd like to repeat a proposal I made before the conference [2] that addresses 
this problem (although it does have scope-creep into a larger versioning issue).

Either stop using the OBS "generated -Release" mechanism and replace it with a 
process/policy based solution designed to meet MeeGo's versioning needs or add 
an incrementing/resetting 'pXX' to the version number to specify the MeeGo 
patchlevel; ie a manual supplement to -release.

   X.Y.ZpRR

This then MUST then be recorded in the .changes file to allow specific changelog 
entries which address specific bug/features to be differentiated and related to 
specific rpms and hence weekly (and maybe even major) releases.

This needs further development to support packages which are developed on the 
new production branch and the old stable branch (eg 1.1 and 1.2). See [2] for 
more details.

I've logged a bug [3]

David

[1] Bug showing the issue biting a MeeGo vendor
https://projects.maemo.org/bugzilla/show_bug.cgi?id=200067

[2] Raising the versioning issue (our archives are broken BMC#10909)
http://www.mail-archive.com/meego-packaging@meego.com/msg00415.html

[3] MeeGo Package Changelogs are broken bug:
http://bugs.meego.com/show_bug.cgi?id=10910

##############################################################

The problem was:
Failed to open the connection to "system" message bus: Failed to connect to
socket /var/run/dbus/system_bus_socket: No such file or folder

<snip>
Which dsme version are you using in the images? The problem has been fixed in
MeeGo Trunk week or two ago

<snip>
It looks to me as if the BMC bug #8330
(http://bugs.meego.com/show_bug.cgi?id=8330) were related. It was fixed to
version 0.61.25 of dsme "by modifying dbus.conf" on Oct 13th.

<snip>
Yeah, but comment #3 tells that the fix is not helping our images. The same dbus 
message occurs even though we have version 0.61.25 of dsme.

-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."