Mailinglist Archive: opensuse-buildservice (197 mails)

< Previous Next >
Re: [opensuse-buildservice] Release number
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Wed, 28 Jun 2006 11:21:34 +0200
  • Message-id: <44A24A1E.7080301@xxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> *From:* Michael Schroeder [mailto:mls@xxxxxxx]
> *Sent:* Wed 28/06/2006 01:43
> *To:* opensuse-buildservice@xxxxxxxxxxxx; 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/
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEokodr3NMWliFcXcRAsUfAKCPAQoyd/FqhctDQDegZBVLF2Rg4wCgifZz
NwCdLxbsenwl+3o4bPbyHjk=
=aImO
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice-help@xxxxxxxxxxxx

< Previous Next >
References