[RFC] Policy for PKG_RELEASE bumps

[Paul Spooren]

Hi,

On 08.08.20 22:40, Sander Vanheule wrote:
> Hi Paul,
>
> Following our brief discussion on IRC, here are my remarks again, so
> others can also comment on them. I'm still pretty new to this packaging
> stuff, so some arguments may already have been made in the past.
>
> On Fri, 2020-08-07 at 12:32 -1000, Paul Spooren wrote:
>> Hi team,
>>
>> currently exist two different ideas on when to raise the PKG_RELEASE
>> of a package.
>>
>> * When functional things change
>>       For example, a OpenWrt specific patch is added
>>
>> * When anything inside the packages ipk file changes
>>       Includes patch and so called "cosmetic" changes outside the
>> Makefile, e.g. replace tabs with spaces.
>>
>> While one could argue that following the first approach lowers the
>> number of non functional updates via `opkg`, it results in packages
>> with different checksums. To keep track of what is reproducible and
>> what not, it is very helpful to see changes in PKG_RELEASE. If not,
>> two seemingly same packages (version/release) have different
>> checksums.
> Looking at other distros (Debian [1], Fedora [2]), it appears to be
> common to reset the equivalent of PGK_RELEASE for every upstream
> version bump. In OpenWrt it appears to mean [3] "our version since the
> dawn of times" instead of "our version of this upstream release".
>
> I feel that having to bump PKG_RELEASE for each and every commit on a
> package, wouldn't be a good idea:
>   * It adds an 'unrelated' change to the patch. PGK_RELEASE should be
>     for keeping track of package versions, not so much for keeping track
>     of source versions.

We have PKG_VERSION to keep track of package versions, and PKG_RELEASE 
to keep track of our modifications. From what I remember we discussed on 
IRC an automatic PKG_RELEASE bump similar to how LuCI sets PKG_VERSIONS, 
which uses git as a counter[1].

I don't see of a PKG_RELEASE bump is unrelated to the patch.

[1]: https://github.com/openwrt/luci/blob/master/luci.mk#L72

>   * It will probably require maintainers to ask people to bump
>     PGK_RELEASE in their patches over and over again.
If we keep the Debian style with resetting to PKG_RELEASE:=1 on every 
PKG_VERSION change, I'll just add a check to our tba CI - it's the same 
issue with a SoB lines.
>> The frequent package updates are likely to happen only when using
>> snapshots, which receives a new firmware on a daily basis anyway.
> Could snapshot builds use automatic package versioning? This would make
> sure that not every single patch needs to bump PGK_RELEASE.
> For example:
> 	1.2.0-1.snapshotXYZ
>
> To make sure that version numbers only ever increase, the snapshot
> version XYZ could be a source timestamp (for that package), or the
> number of commits in that package. One argument against the latter, is
> that the package version number would then be related to a commit in a
> non-obvious way.
> Fedora for example, uses a DATE.REVISION format for snapshot versions.
> So their snapshot packages (for that day) may not sort correctly, but
> will in any case point to a specific commit.
>
> If the commit history between a release build and snapshot build is the
> same, you may want both to have the same package version. So that might
> be a special case where you don't add a snapshot version tag. Unless
> you don't mind two package versions pointing to the same code version.
> The latter would, in my opinion, be less of an issue than a single
> package version being used for multiple source versions.

Jow was thinking to improve the ABI handling of packages to allow 
incremental (instead of full) package rebuilds. Maybe within that work 
some package-renaming happens. My key point here is however that I want 
to simplify the work of people working on reproducibility. From my 
experience it's easier to compare things when both the unique package 
identification is possible (via PKG_VERSION+PKG_RELEASE) and the build 
system revision is known[2]. By sticking to my proposed policy, we solve 
the former :)

[2]: https://patchwork.ozlabs.org/project/openwrt/list/?series=191059

>> Please share your thoughts. If there are no strong arguments against
>> bumping the PKG_RELEASE on anything that changes the resulting
>> package content, I'd like to make that a policy.
> [1] https://readme.phys.ethz.ch/documentation/debian_version_numbers/
> [2]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
> [3] commit 9c170cb92f4fbb316592c11567a080eb3f6a1fc3
>
> --
> Best,
Paul