| Git Clone URL: | https://aur.archlinux.org/goldendict-webengine-pr-git.git (read-only, click to copy) |
|---|---|
| Package Base: | goldendict-webengine-pr-git |
| Description: | Feature-rich dictionary lookup program supporting multiple dictionary formats |
| Upstream URL: | https://github.com/goldendict/goldendict/pull/1542 |
| Licenses: | GPL3 |
| Conflicts: | goldendict |
| Provides: | goldendict |
| Submitter: | vedg |
| Maintainer: | vedg |
| Last Packager: | vedg |
| Votes: | 8 |
| Popularity: | 0.063289 |
| First Submitted: | 2022-12-02 11:35 (UTC) |
| Last Updated: | 2024-05-31 10:28 (UTC) |
You are right. I didn't know about VCS version-checking features of AUR helpers and that makepkg git history is lost (except for the version used in the last rebuild).
Implemented my proposed alternative stable version approach. Feel free to suggest further improvements.
The local git repo is transient, usually unavailable or difficult to access. It is destroyed and recreated on every rebuild, producing a new random hash with no inherent meaning.
Only if the user removes the package sources and clones anew before each rebuild, which is wasteful.
Any sufficiently long sequence of random numbers would not be expected to be monotonically increasing. I have been observing version strings generated by this package from rebuilds on a build server for over a year. They are definitely not monotonically increasing, and have resulted in wasted resources on unnecessary rebuilds, including excess carbon emissions and contributions to climate change, if you believe or care about such things. No other package I've encountered randomly generates hashes on every build like this.
This is a valid point. You should have mentioned this primary motivation from the beginning. Do you refer to a build server of the Chaotic AUR repository?
If you are asking for a better hash scheme than the one I proposed, I don't have one at the moment. You could devise an entirely different scheme. Anything that lends consistency to builds across separate systems, that isn't just random, would be an improvement.
How about the following alternative: concatenate (with a separator) a portion of the SHA sum of each commit that is a parent of a commit authored by the user GD WE PR merger, but is not authored by GD WE PR merger itself. Such a version would include all enabled _pull_we branches and would use info available in the local git repo instead of relying on GitHub API. A logical ordering of the parent commits can be found experimentally (assume that users do not reorder the pull lines in the PKGBUILD).
It cannot be used to determine whether the sources have actually changed, whether a rebuild is necessary.
The first two parts of the version (tag and "r10") can be used for that, because both we/webkit-or-webengine and master branches are stable (not force-pushed into).
It is not useful for bug reports.
The first two parts of the version (tag and "r10") can be used in case _pull_we isn't uncommented. More detailed information can be obtained from the local git repo.
Version numbers are not monotonically increasing.
Are you sure about this? The tagged versions we* are monotonically increasing and the "r10" part is increasing as well (remember, no force-pushes).
_pull_we isn't actually used in the current PKGBUILD, so doesn't matter that it's ignored.
But users can easily uncomment/modify those lines. The proposed supposedly unique and sufficient generated version would be misleading then. The current actual commit SHA sum can be used to determine which branches have been merged in the local git repo.
The current commit hash in the version number is random. The following pkgver() will generate a stable hash:
How is the random version number a problem? It matches the merge commit SHA sum in each user's local goldendict git repo and the version displayed in GoldenDict's Help=>About. The two merged commits can be found in the local git repo. Plus the version contains the number of commits over the tag (e.g. "r10").
Your suggested pkgver() ignores any other potentially merged branches (_pull_we in the PKGBUILD).
Pinned Comments
vedg commented on 2022-12-02 11:54 (UTC)
This package is based on my Qt WebEngine pull request (Upstream URL). The upstream master branch is pulled in by default. A comment in the PKGBUILD advises what to do if merging upstream master fails.
If you wish to include a fix or a feature from some of my other pull requests, uncomment and possibly modify one or more of the
_pull_welines in the PKGBUILD.