Bug 135826 - build.rpm build script does not honor get_version_number.sh
Summary: build.rpm build script does not honor get_version_number.sh
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Development (show other bugs)
Version: Final
Hardware: Other Other
: P5 - None : Critical
Target Milestone: ---
Assignee: Michael Schröder
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-29 12:49 UTC by Andreas Gruenbacher
Modified: 2006-02-16 00:06 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Gruenbacher 2005-11-29 12:49:21 UTC
The build script does not replace the Version tag with the output of get_version_number.sh in the version that is part of build.rpm on 10.0. This functionality is critical for kernel module (aka driver) packages, which must have the current kernel's version in their version tag.

Alternatively to get_version_number.sh, build could be changed to allow rpm macros in the Version field, so that we could use something like:

  Version:  %(rpm -q --qf '%{VERSION}_%{RELEASE}' kernel-source)

in spec files. IMHO this would be the much more elegant solution anyway, as vanilla RPM would support it just the same.
Comment 1 Michael Schröder 2005-11-29 13:08:31 UTC
It never did, as it does no "prepare_spec".

The %() proposal might be elegant, but I don't see how I can implement it as I cannot call rpm from the autobuild scheduler. (It also doesn't call get_version_number.sh...)

Hmm, and automatic release number increments on checkin also won't work.
Comment 2 Andreas Gruenbacher 2005-11-29 13:26:40 UTC
Indeed, we cannot call get_version_number.sh outside of the build environments, either. But we do have some packages where the version is only determined during build, with either mechanism.

If Autobuild relies on the package version otherwise, then that's actually broken for such packages. Is there any chance this could be fixed, maybe by using a short-time workaround like writing a magical "version from the last build" into a special file, or whatever?
Comment 3 Michael Schröder 2006-02-15 23:51:09 UTC
I guess this is fixed by the new KMP scheme?
Comment 4 Andreas Gruenbacher 2006-02-16 00:06:09 UTC
It was fixed by allowing macros in the Version tag, which we (you) added in the meantime, thanks.