On 25/10/10 17:37, Anas Nashif wrote:
On 2010-10-25, at 11:44 AM, David Greaves wrote:
The problem is that using the .changes file I cannot look at two rpms with
different -release values and know: * Was there a source change * Was there
a packaging change * Were any bugs/security issues fixed
Just to clarify the versioning:
Package Versions look like : X.Y.Z-R.B
* X.Y.Z is the Version number - determined by the source package.
* R is the release number which is automatically incremented by OBS whenever a
source/packaging changes (eg a check-in or request acceptance)
* B is the build number which is incremented when the package is rebuilt due to
a dependency change.
Correct?
if you compare 2 packages with different same release but different build
numbers, then there should not be any diff in the changelog if you compare 2
packages with different release number, there should be a log entry related
to that change, since obs bumps the release when there is a source change.
OK ... but this means I can't look at the changelog to determine where a change
was made?
Nor can I copy the contents of a package directory, build it and have a
compatible rpm. If I take source out of the OBS and put it back I get different
results?
I am a bit concerned by this. It seems to mean that correctly versioned MeeGo
rpms cannot reasonably be rebuilt from source outside of the core OBS. Is this
correct?
Now... if MeeGo were only interested in the core MeeGo implementation then I
could understand it if we say "we're OK; it's our process and it works."
BUT MeeGo is a _reference_ implementation. I should be able to easily copy it
and reproduce it. Making life even slightly more complex for vendors who build
against MeeGo is not a good idea. So please don't dismiss this discussion out of
hand.
OK ... a few policy clarifications next:
The diff in the changelog should give you a description of what has changed.
source change mandates a version change, thats why we reject package changes
that change the source directly instead of submitting a new tarball version.
OK. That's clear policy. Is this as simple as 'changes to any file other than
the .spec and .changes are not allowed without a Version bump'
If no source change then most likely a patch has changed or something in the
packaging.
Sorry. This seems to contradict: "...source change mandates a version change..."
and "... we reject package changes that change the source directly instead of
submitting a new tarball...". So are you saying that source changes made by
patching that keep the Version the same are permitted?
(Or am I being dim and there is another use for patches outside of src changes?)
If a package just rebuilds because of a dependency, this package is also
subject to QA, since an API might have changed.
Yes. In the automation process we distinguish between changed packages and
rebuilt-packages which are potentially subject to regression tests.
...and back to the -Release numbering:
FYI ... I'm *thinking* that we could have a policy that says that any change
should be recorded in the changelog *with a version change*. If this is a
packaging only change then appending 'pXX' will explicitly identify a change.
This means that the -R.B will be an aide to development but the X.Y.Z triplet
will define the package source/packaging.
If there's a reliable way to get this -release into the changelog and to ensure
that when I copy the "inputs" to a package I get the same versioned RPM then
that would resolve this.
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
