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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
