@hammy was soliciting input on how to version RPM builds, given that a version of a build:
My observation is that a lot of these fit into the category of binary artifacts. Namely the original source tarballs, the resultant SRPMs, and the resultant binary RPMs. They have independent but related versions, namely an upstream source revision and a build revision.
I would suggest a scheme for dealing with them as follows:
Again let me know if this addresses the original concern @hammy; or anyone else is of course free to comment as well.
- Uses a specific version of source that originates elsewhere (usually in tarball form)
- Uses RPM spec files that originate elsewhere, but applies modifications to them to result in the final spec file to be used
- Generates an SRPM that has everything needed to perform the build, but is too big to fit in version control
- Finally, generates a binary RPM that is installable by the end user
My observation is that a lot of these fit into the category of binary artifacts. Namely the original source tarballs, the resultant SRPMs, and the resultant binary RPMs. They have independent but related versions, namely an upstream source revision and a build revision.
I would suggest a scheme for dealing with them as follows:
- All binary artifacts (original source tarballs, built SRPMs, binary RPMs) are versioned and stored in a separate artifact repository and not in source control
- The artifact repository can be the SGUG S3 bucket (with CloudFront CDN distribution), which should be fast, exceptionally durable, and easy to mirror for anyone interested
- Upstream packages:
- Should still be stored (cached) in our artifact repository just in case they disappear from upstream later
- Retain their original upstream version number
- SRPMs and binary RPMs:
- Treated the same way as each other even though the SRPMs may be used as an intermediate product in a build process
- Versioned according to the upstream version plus a build version (and distinguished by target IRIX version / architecture, etc.)
- Stored in a yum repository compatible format
- Build versioning (for SRPMs/RPMs)
- Distinguish between snapshot and release with a suffix
- Snapshot: a development build between official releases, not meant to be stable or relied on by users other than in a testing capacity
- Release: a finalized release (whatever that means to someone, but ideally in a deliverable state, stable, and tested)
- Store them in different yum repository roots so that the users won't accidentally install snapshot versions?
- Use date / time stamp versioning of snapshot artifacts to avoid having to synchronize version numbers with multiple developers (e.g. a Major.Minor.YYYYMMDDHHMMSS format in UTC)
- Use major / minor / incremental versioning of releases, as releases should be coordinated by all involved developers
- Distinguish between snapshot and release with a suffix
- Build process
- I think the key part of the above with regards to not maintaining SRPMs in version control is that everything necessary to create the SRPM, and to proceed thereon to a binary RPM, should be version controlled
- Spec files should either be version controlled directly, or alternatively a set of patch files used to create the spec file along with a script to fetch the spec file and make that happen as part of an automated build process
- The build scripts themselves should be versioned
- The build scripts should perform some semblance of:
- Downloading the upstream sources from the artifact repository
- Using (or creating and using) the spec file to generate the SRPM
- Executing the build process of turning an SRPM into a binary RPM
- Optionally (if credentials are present) uploading the resultant SRPMs and binary RPMs to the destination yum repository, although ideally in an end state this would be handled only by a CI system
Again let me know if this addresses the original concern @hammy; or anyone else is of course free to comment as well.
Last edited: