-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
*From:* Michael Schroeder [mailto:mls@suse.de] *Sent:* Wed 28/06/2006 01:43 *To:* opensuse-buildservice@opensuse.org; Robert Schiele *Subject:* Re: [opensuse-buildservice] Release number
On Wed, Jun 28, 2006 at 10:04:49AM +0200, Robert Schiele wrote:
On Wed, Jun 28, 2006 at 09:47:17AM +0200, Michael Schroeder wrote:
Currently the build service ignores the value you put in the release tag and replaces it with a value it maintains internally (number of checkins . number of rebuilds). There should be a way to specify a *minimum* value, though.
Why not just using the specified as a minimum?
Yes, we could do that. Sounds like a good idea to me. (I'll have to pare the specfile on the upload for this, though.)
So it's a rather intrusive change, as you'd have to introduce spec file
parsing on upload.
Because of that, my project manager instinct would say -1 (but that's
Adrian's job ;))
Would it be easier to set the minimum value for the release through
project metadata (web-UI / osc editmeta ...) ?
Also, consider that if you use the Release: tag as the minimum value on
every spec file upload, then the build must also modify the spec file to
actually set the current %{RELEASE} into the Release: tag.
Consider the following scenario:
- - first time spec file upload, foo.spec, containing
Release: 100
- - trigger the build,
* %{RELEASE} would be 100.1
* spec file unmodified, Release: is still 100
- - make a change to the spec file, upload again
* Release is unchanged in the spec file, hence: 100
- - BS parses the Release: tag for the minimum %{RELEASE} (which is 100)
- - trigger the next build
* %{RELEASE} would be 100.1 again
So from this scenario, one would say: only parse the Release: tag on the
first spec file upload.
Then again, consider this scenario:
- - first time spec file upload, foo.spec, containing
Release: 100
- - trigger the build,
* %{RELEASE} would be 100.1
* spec file unmodified, Release: is still 100
- - make a change to the spec file, Release: is modified (by the
packager), upload again:
* Release is changed in the spec file, say: 200
- - BS parses the Release: tag for the minimum %{RELEASE} (which is 200)
- - trigger the next build
* %{RELEASE} would be 200.1, as expected
So... I'm not sure it really makes sense to use the Release: tag for
that purpose.
If the minimum %{RELEASE} value is set through project metadata, it's
just a matter of doing the following, when building:
- - compute %{RELEASE} (as it is done now)
- - if (computedRelease < minimumReleaseFromMetadata) {
computedRelease = minimumReleaseFromMetadata;
}
(of course, that doesn't include computing the part of %{RELEASE} that's
behind the ".")
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\