MSYS2 specific linter

[lazka]

Just a braindump/copied from my notes:

There are already Arch specific linters like namcap, but we will never upstream any changes and we have to fight Linux things, so we might look into creating our own.

There are multiple things to lint/validate, maybe these should be split into separate commands:

• The PKGBUILD file
  • shellcheck?
  • lint PKGBUILD directory (source files not included etc)
  • msys2_references pointing to valid names
  • provides etc. versions are not empty: https://github.com/msys2/MINGW-packages/issues/21045
• The SRCINFO file
  • license spdx
  • mingw pkgname and pkgbase naming
  • PKGBUILD: drop default options?
• The built package alone
  • Are static libs usable: https://github.com/msys2/MINGW-packages/pull/12562#issuecomment-1214825969
  • Do they contain symlinks?
  • no absolute paths in .pc files?
  • +dynamicbase not being set for cygwin binaries (peflags..)
  • missing .pyc files for .py files
  • is the python version 0.0.0 (points to missing setuptools-scm)
  • https://github.com/jeremyd2019/pelint
  • things linking against external DLLs (for example: https://github.com/msys2/MINGW-packages/issues/12614)
  • are the .exe/.dll valid (use pefile maybe to detect problems maybe?)
• The built package compared to the last on in the repo
  • large size increases/decreases compared to the previous package version
  • large increase/decrease of file count compared to the last release
  • Changes in the .pc files
  • Changes in the file list
• The built package or a set of packages integrated into the repo, in relation to all other packages and the repo
  • pip version checks for reverse deps
  • removed DLLs and symbols breaking other packages (https://github.com/jeremyd2019/package-grokker)
  • DLL address conflicts for msys DLLs with related packages
  • Does adding the package create any new dependency cycles?
• The repo itself and the srcinfo collection as present in git
  • files in git that have a lower version than in the repo
  • files that have conflicts with other packages but the packages don't conflict
  • existing replace cycles leading to endless replaces
  • missing .pyc files

All this could run in CI and stored as a markdown CI status report, to make reviews easier.

[jeremyd2019]

Maybe we should have a rule that pkgbase must be the same as the directory that the PKGBUILD file is in? This is true in most cases already, and would simplify scripts that look for the PKGBUILD file.

[jeremyd2019]

did a quick script over MINGW-packages srcinfo.json for packages where path != pkgbase:

mingw-w64-python-mapbox-earcut  !=  mingw-w64-mapbox-earcut
mingw-w64-livechart-gtk3  !=  mingw-w64-live-chart-gtk3
mingw-w64-wxSVG  !=  mingw-w64-wxsvg
mingw-w64-python-pyfastbti-git  !=  mingw-w64-python-pyfastbti
mingw-w64-wb32-dfu-updater_cli  !=  mingw-w64-wb32-dfu-updater
mingw-w64-rake-compiler  !=  mingw-w64-ruby-rake-compiler
mingw-w64-python-defusexml  !=  mingw-w64-python-defusedxml
mingw-w64-osgqtquick-git  !=  mingw-w64-osgQtQuick-git
mingw-w64-zig empty srcinfo
mingw-w64-openxr  !=  mingw-w64-openxr-sdk
mingw-w64-gammaray-qt5  !=  mingw-w64-gammaray
mingw-w64-hclient-git  !=  mingw-w64-hclient
mingw-w64-ghc empty srcinfo
mingw-w64-python-pyfasttextureutils-git  !=  mingw-w64-python-pyfasttextureutils
mingw-w64-gtest  !=  mingw-w64-googletest
mingw-w64-faudio  !=  mingw-w64-FAudio
mingw-w64-kdstatemachineeditor-qt5  !=  mingw-w64-kdstatemachineeditor
mingw-w64-streamlink  !=  mingw-w64-python-streamlink

and MSYS2-packages

perl-getopt-argvfile  !=  perl-Getopt-ArgvFile
perl-IO-stringy  !=  perl-IO-Stringy
nghttp2  !=  libnghttp2
perl-spiffy  !=  perl-Spiffy

[ikspress]

As far as I'm concerned, not only shellcheck is needed, but shfmt as well. A standardized coding style is important.