Bug#767414: RFP: 2048 -- Simple number game for the text console
Hello.
Here are some comments about the current packaging.
Hope this helps…
As upstream contributor, you should merge your changes into the
original project at https://github.com/mevdschee.
Your fork misses README.md, latest bug fixes,
and the original project would probably welcome a manpage and
improvements in the Makefile.
The attachment fixes cosmetic issues in the manpage
(https://liw.fi/manpages/),
and contains many suggestions for the Makefile:
* allow prefix /= /usr
* avoid as many repetitions as possible, so that any renaming or version
change is easyer
(I suggest a name starting with a letter for the package and executable)
* reduce the subshell runs, declare .PHONY targets, use := variables
(for performance)
Once an upstream tarball is released
* without any debian/ subdirectory (there may be other distributors)
* without .gitignore (the tarball is unrelated with the VCS)
* with explicit authors and license
* maybe with a short ./changelog file, either referencing the version
control system or manually listing changes.
* visible somewhere on the web (for automatic detection of new versions)
* maybe signed by your electronic signature
you can start the Debian packaging.
debian/2048.debhelper.log
debian/2048.substvars
debian/files
show that you have committed without cleaning your working directory.
debian/changelog should only contain the history of the official
Debian packages (currently, only one). In other words, it only sees
the debian/subdirectory.
In normal circumstances, changes to the upstream sources should be
mentioned in ./changelog (or the VCS it refers to).
Text files should end with an empty line (it helps diff tools).
Your package is ready for debhelper 10 and Standards-Version 4.1.0.
control/Vcs-* and copyright/Source changes should be self-explaining.
I hate trailing whitespaces, but YMMV.
Once upstream releases visible tarballs, adding a watch file scanning
new upstream releases and checking signatures would be a good thing.
See uscan(1).
Reply to: