On 25/10/10 15:32, Arjan van de Ven wrote:
On 10/25/2010 7:31 AM, David Greaves wrote:
On 25/10/10 15:00, Anas Nashif wrote:
On 2010-10-25, at 9:40 AM, David Greaves wrote:
http://wiki.meego.com/Packaging/Guidelines
An upstream package may have a fixed x.y.z and we can't use the
-release
extension for packaging only changes.
Under Version, it already says:
Post-release packages: Packages released after a "final" version. These
packages contain the same numeric version as the "final" version,
but have
an additional non-numeric identifier.
For clarity I've added "This mechanism may also be used for
packaging only
changes to an upstream package".
Comments?
I am not sure I understand this. Can you give an example?
If you can see:
https://projects.maemo.org/bugzilla/show_bug.cgi?id=200067#c8
quote:"To be exact, it's 0.61.25-1.1 and the fix is in 0.61.25-2.1.
(As in, same
upstream version, newer packaging.)"
If the packaging changes then the proper package version should be
incremented - right? And since the source is not modified and the
-release can't be used then a non-numeric should be appended.
David
eh
OBS manages the release for you automatic so that it always increments
don't think we need to specify anything here ;)
Yes... I can see that point.
Perhaps another question: where do I find the .changes that tells me that bug
BMC#8330 was fixed by a packaging change and I need 0.61.25-2.1 and not
0.61.25-1.1 ?
I apologise if I'm asking a silly question - I've spent less time than I'd like
doing any MeeGo packaging. I am however looking at automating this type of
verification and would appreciate getting a thorough understanding.
I completely understand that changes to packaging in the home area during
development wouldn't need such things. However once promoted to an area where
other people depend on the package (and may have created an image with an older
version) it seems hard to tell by examining the release that a relevant change
has happened and it's not just a dependency rebuild.
In particular, in order to verify policy, automate processes and hopefully
remove some drudge-work as we improve efficiency then I need to have clarity on
the rules.
So:
http://build.meego.com/package/view_file?file=dsme.changes&package=dsme&project=Trunk
says:
# * Wed Oct 13 2010 Markus Lehtonen <[email protected]> - 0.61.25
# - Fix BMC#8330 by modifying dbus.conf
#
# * Fri Oct 01 2010 Markus Lehtonen <[email protected]> - 0.61.25
# - Version bump to 0.61.25
# - Bugfixes plus some of the previous MeeGo-patches now merged upstream
So I have 2 changes which are ~2 weeks apart and have the same version?
In the specific case here's a couple of quotes from the pmo bug:
"The following dsme packages are installed in the image:
libdsme-0.61.4-2.5.i586
dsme-0.61.25-1.1.i586"
So clearly - by checking the changelog - I see that "Fix BMC#8330 by modifying
dbus.conf" is in 0.61.25.
and:
"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."
Note that the developer didn't note (or say) it wasn't fixed in 0.61.25-2.1 ...
Another case that springs to mind as we automate ... if I look at the packages
for an image created on 12 Oct and, a couple of days later I use the image
manifest to get a list of bugs fixed by checking the package version in the
package DB against bugzilla... I see that BMC#8330 is fixed. How do I know not
to re-open the bug?
Since the -release changes upon a triggered rebuild (and is therefore indicating
a candidate for regression testing) *and* changes on a change to packaging I'm
wondering if we shouldn't have a policy that requests a new version number each
time the source+packaging code is changed in Trunk?
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
