Archive:PackagingDrafts/DisttagsForRawHide
From FedoraProject
Contents |
What are disttags?
Disttags are optional parts of the Release tag of a package. In their simplest form they get appended to what would be the classical Release tag, i.e. the Release tag gets suffixed with a disttag.
The disttag is an abbreviation of the release like "fc5" for instance. It is composed out of the abbreviated distribution name and the release's version.
What are disttags useful for?
The least useful reason to apply them to a package is to have the release this package was build on or for in the package's name.
The true power of the disttag method is that for a lineup of releases within a distribution it can help maintain the same specfile across several releases while ensuring that these packages are still in proper rpm-ordering. That means that the upgrade paths are safe.
Why should the same package exist in different releases of the distribution with different names, can't we simply reuse the same package all over again?
In some cases, yes. If the package does not really depend on the release, e.g. the binary output is always the same, then you shouldn't use a disttag.
But most packages will depend on the different (build) environments the different releases offer (for example gcc and glibc) and will produce different binary packages, although the sources and specfiles are the same!
Otherwise the different releases need to artificially change the Release tag to ensure that the packages will upgrade to the next release's one.
disttags remove the neccessity to bump the release tag if the sources (contents of src.rpm) remain the same
What about rawhide?
Rawhide's internal versioning after release X is X.89 until the first test release, which is versioned X.90. The second test release is versioned X.91 and so on.
The disttag in this case can be either the disttag of the next release (current practice) which is fc<X+1>, or something reflecting the above versioning.
From the non-rawhide perspective it is the same outcome, the next release will have packages with a disttag of fc<X+1>.
For rawhide the sliding disttags mean that all packages with a disttag will get automatically rebuilt when the disttag is changed. This means that at the very least for the test releases these packages get rebuilt.
But one can also use the disttag in rawhide to force mass rebuilds at any time one wants to. Say the disttag is fc6.89, e.g. rawhide is targeting FC7 and is not yet doing test releases. If a mass rebuild is needed before (and not for) the first test release one can bump the disttag to 5.89.1.
Pros and Cons
Pros
- mass rebuilds become very automated. Packages using the disttag idiom don't get in the way (unless the build breaks), one only needs to cater for the ones w/o. So the mass rebuild problem is very much reduced.
- sane upgrade paths even within rawhide and the test releases.
- rawhide packages can't be mistaken with these from the next release.
- No changes of the non-disttag part of the Release tag.
- Therefore also no changes at all of the specfile and therefore no artificial branching solely due to rebuilds.
Cons
- requires that changelogs due to mass rebuilds are not written. There are two religions on this, one that wants every change in rawhide changelogged and one that doesn't want to see the cluttering noise in the changelogs. Viewed from another perspective: there are those that consider the changelog part of the src.rpm and those that consider it part of the binary/noarch rpms.
- The disttag will by construction force a mass rebuild from testX to testY and for the final test release to the proper release. This may not always be what one wants (but the the disttag of say a release candidate/test3 could already be bumbed to the final one).
- The disttag obviously varies in length and number of rpm comparable segments. Versioning constructs that place something behind the disttag will break.
