Bagas Sanjaya wrote:
Hello,
I've filed RFP for PCYNLITX sometimes ago [1]:
In PCYNLITX download page [2], it can be installed by using installation
script. However, after examining install
script, I noticed following:
- PCYNLITX doesn't employ version numbering like any other project/packages. It
would be difficult to identify
which is the latest version. So I use version number 0.0~git20190606 in RFP
report.
I think convention is to add the git commit hash on the end of that as
well, to pin down exactly which source version was used to build the
package. IIRC the New Maintainer's Guide either has an example or links
to another document that has one, so that your package versions sort
properly.
- The script install wxWidgets library from third-party repository, not from
Debian. It use codelite repo (for Stretch):
apt-add-repository 'deb http://repos.codelite.org/wx3.0.4/debian/
stretch libs'
Your package will have to depend on the stock Debian version of this
library, unless there are specific modifications in this other version
that are strictly necessary. If the modified version of this library is
necessary, it must also be packaged within Debian, or at least shipped
in the source and binary package you're creating (and strongly justified
if you do this); adding third-party repositories isn't acceptable.
- Evince will be installed as runtime dependency, possibly for documentation.
For non-GNOME users (KDE, XFCE, etc.)
which use different readers (like Okular and Atril) this can bloat their system
and become unnecessary.
Unless the software itself actually uses evince internally, you don't
need dependencies on anything for reading documentation.
- All steps are performed using sudo. If the script is run by root user, this
will be redundant, since the installation
is done by root privileges.
If I will packaging PCYNLITX for Debian, any suggestions, assuming that I have
read New Maintainers Guideline and
related Debian packaging documentation?
You will have to inspect and understand the steps that installer script
takes, and convert that into a proper Debian package based around either:
- the upstream tarball retrieved in the first command that script
runs, or:
- a git commit or tag
Without inspecting the tarball itself, based on the dependencies it
installs it looks to me as if it just contains precompiled binary files;
this would not be acceptable in Debian's main archive, or in contrib.
It *may* be acceptable in non-free. Check the build process that
creates that tarball from the upstream git repository; you may have to
base your package entirely on the git repository rather than any of the
bundled "release" files.
-kgd, just a moderately experienced observer on the packaging process
