(restoring Arjen to the cc list .. sry)
On 26/10/10 13:38, Anas Nashif wrote:
On 2010-10-26, at 1:01 PM, David Greaves wrote:
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.
Exactly. That's not "looking at the changelog" that's "extracting 2 changelogs
from different packages, doing a diff and *then* seeing a changelog entry".
Which, IMHO, kinda defeats the point of a human readable changelog :)
I think this is is one of my concerns; a changelog is supposed to tell me all I
need to know about when changes were made. Currently they don't.
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.
And this is another.
What happens when a spec depends on >=X.Y.Z-R instead of >= X.Y.Z
(Which sounds reasonable given a bug is fixed in X.Y.Z-R)
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.
OK ... there's a debate to be had there about it being inappropriate to rebuild
an rpm outside the core OBS. However we don't need to go there... what if I'm
trying to do an ARM5 re-build or something? Clearly I'm not looking at binary
compat. I may even have my own OBS. However the rpm versioning will be different
for different images... how confusing is that? Not to mention the dependency
graph now being *build* specific.
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 - is that a reasonable requirement though?
Should a vendor be able to duplicate the OBS and be able to build MeeGo for,
say, a slightly different architecture?
OK ... a few policy clarifications next:
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.
Thanks - noted
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.
Thanks - noted
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.
Agreed - but if we can use a seperator of '-' X.Y.Z-R then we could permit a
seprator of 'p' for packaging/patchset.
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.
See above about dependencies and rebuilding. If we can't control -R and we use
it to distinguish bug fixes/changes then different builds of MeeGo with the
exact same rpm_X.Y.Z-R will have different bugs.
The
compliance document should only require the same version + patches (AFAIK
that is the case, but I might be wrong).
So does this supports the need to be able to rebuild MeeGo in a consistent way.
Incidentally... I think a solution to this entire problem is as simple as adding
an incrementing/resetting 'pXX' to the version number to specify the MeeGo
patchlevel; ie a manual supplement to -release.
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
