Sign in or sign up before continuing. Don't have an account yet? Register now to get started.
Packaging auxiliary files
Thanks again for adding the VERSION file and making `scli --version` work!
I realized that the README file might be needed too: `scli` tries to open it on `?` keypress. Could you please add it too?
I see that the VERSION file ends up in the `/usr/bin` dir, which is probably not what users expect (it's the only non-executable in that dir). I don't know the conventions well enough, but maybe `/usr/share/python3-scli` would be a good location?
*However*, `scli` executable expects to find the `VERSION` file in the same dir, so .. Maybe symlinks will do? (placing the `scli` executable with `VERSION` in e.g. `/usr/share/..`, and making a symlink `/usr/share/../scli` -> `/usr/bin`).
I see in the [FreeBSD Ports](https://www.freshports.org/net-im/scli) they do achieve to split them. Haven't looked into how it's done there; maybe even by patching the python source (a less desirable solution)
NB: a nifty one-liner to do `git archive` and extract the VERSION file (like [currently done](https://gitlab.com/packaging/scli/-/blob/master/.gitlab-ci/build.sh#L36-37)):
git -C ~/tmp/scli archive HEAD | tar -C /tmp/scli -xf - VERSION
Incidentally, what is the `git --version` in the gitlab CI's used for packaging? What matters is whether it's >= 2.32, see [recent discussion](https://github.com/isamert/scli/issues/151#issuecomment-1005103489).
Again, this VERSION business is not a big deal, so whichever is the easiest solution will do.
issue