Hello,
a miror question about / problem with the Release: number:
In the specfile, I have to set a release number: Release: 42 (If I don't, rpm complains and the build fails.)
The build service edits this number when building the package and sets it to 1.42 then 2.42 then 3.42 etc. This makes the release number in the specfile quite useless because it's only on the second position.
The behaviour can also cause problems when someone imports a package to the build service.
Say I have released a manually built foobar-1.0-42 package, then move to the build service and do some small changes without changing the version number. The build service will compile a foobar-1.0-1.42 package which looks "older" to RPM :-(
Are there any plans to change the behaviour regarding the release number?
Regards,
Christian Boltz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Christian Boltz wrote:
a miror question about / problem with the Release: number:
In the specfile, I have to set a release number: Release: 42 (If I don't, rpm complains and the build fails.)
Indeed, Release: is a mandatory spec file tag.
The build service edits this number when building the package and sets it to 1.42 then 2.42 then 3.42 etc. This makes the release number in the specfile quite useless because it's only on the second position.
Ummm... I'm pretty sure this is supposed to be done on the *second* field, not the first one.
Adrian ?
The behaviour can also cause problems when someone imports a package to the build service. Say I have released a manually built foobar-1.0-42 package, then move to the build service and do some small changes without changing the version number. The build service will compile a foobar-1.0-1.42 package which looks "older" to RPM :-( Are there any plans to change the behaviour regarding the release number?
Either something is misconfigured or it's a bug, because from what I know, it is actually meant to be performed on the second part of the Release: (behind the dot). I would doubt it's a bug because quite a few builds have already been done with the Build Service. Maybe a regression that has been introduced today ?
cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\ pascal.bleser@skynet.be guru@unixtech.be __v The more things change, the more they stay insane.
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice-help@opensuse.org
hi,
i usually leave the release number at 0 than you get: x.y where X is the number of commits to your package and y the number of rebuilds, either from clicking this trigger rebuild or due the rebuilding of a package in your buildrequires.
and yes this is required to have properly incrementing release numbers.
just my 2 cents.
darix
On Tue, Jun 27, 2006 at 10:29:53PM +0200, Christian Boltz wrote:
Hello,
a miror question about / problem with the Release: number:
In the specfile, I have to set a release number: Release: 42 (If I don't, rpm complains and the build fails.)
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.
Cheers, Michael.
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?
Robert
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.)
Cheers, Michael.
Em Ter, 2006-06-27 às 22:29 +0200, Christian Boltz escreveu:
Are there any plans to change the behaviour regarding the release number?
AFAIK, Mandriva uses a macro called %mkrel, which instructs their build server to auto create the release number.
Release: %mkrel
If the packager doesn't want this to be automatic, then he can force the number in one of the two ways:
Release: %mkrel 1 or Release: 1
In the past, (also AFAIK) the spec files for Conectiva (which has merged with Mandrake to form Mandriva) didn't need to have the release tag, since the specs were commited to an SVN server and their build server automatically created the release number based on the SVN revision number. That way the release number would always be a sequential number no matter what the version is (so, for example, you could have 1.0-55 and 1.1-78 two weeks later).
Jus my 2c to help you making the decision... :)
AFAIK, Mandriva uses a macro called %mkrel, which instructs their build server to auto create the release number.
Release: %mkrel
If the packager doesn't want this to be automatic, then he can force the number in one of the two ways:
Release: %mkrel 1 or Release: 1
Do you plan to implement something like this?
I have an issue with OpenVZ suse kernels because of the auto release assign. kernel-source packages have different from binary packages release number. This follows in nightmare while building unsupported modules over this kernels because of the wrong symlinks.
Am Thursday 17 August 2006 11:08 schrieb Dmitry Mishin:
AFAIK, Mandriva uses a macro called %mkrel, which instructs their build server to auto create the release number.
Release: %mkrel
If the packager doesn't want this to be automatic, then he can force the number in one of the two ways:
Release: %mkrel 1 or Release: 1
Do you plan to implement something like this?
I have an issue with OpenVZ suse kernels because of the auto release assign. kernel-source packages have different from binary packages release number. This follows in nightmare while building unsupported modules over this kernels because of the wrong symlinks.
This is an open topic to be discussed atm.
In general I do see two possibilities:
1. declare such dependencies to %release as illegal. Because a rebuild does not make a package (kernel) incompatibel.
2. support release number copies via build service links.
I am atm in favour of solution 1., but our kernel people needs to agree ...
bye adrian
buildservice@lists.opensuse.org
-
Adrian Schröter -
Christian Boltz -
Dmitry Mishin -
Marcus Rueckert -
Mauricio Teixeira (netmask) -
Michael Schroeder -
Pascal Bleser -
Robert Schiele