On 2010-10-26, at 1:01 PM, David Greaves wrote: > 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?
Yes. > >> 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? why can't you? If you compare two packages where something has changed, then there should be a changelog entry. > > 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? You get the same version, but with different release.build number, because those are maintained in the MeeGo build system. > > 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? Correct. Correct version-release.build is a relative to where you have built the package. If you build a package out of obs without changes and just for fun, then you get different results. Having same version exactly (release.build) does not mean anything and gives the wrong impression that the package is compatible or bit by bit similar, while it is actually not, since the build environment is not the same, lots of variables around building an rpm can change, so, to be compatible, the content of the same source version is what actually count, not the binary. > > 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. > I am not dismissing anything yet. > > 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' No, the version can be the same and should reflect that of the upstream software. We can add hundreds of patches and the version would still be the same, the release.build however would change in the build system. > >> 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?) Source here means the original source we get from upstream, not the additional patches we add to fix a bug or adapt it to meego. We cant change the version number arbitrarily, that is something controlled by the provider of the software, not meego. The only thing we control is the release.build. > >> 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. We do not control X.Y.Z and we should not touch it. > > 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. Not sure why you want that. If you take something out of the meego build system you are following your build process, so any attempt to keep the rpm version-release.build will be artificial and would not mean anything. The compliance document should only require the same version + patches (AFAIK that is the case, but I might be wrong). Anas > > 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
