Several changes to improve maintainability, readability and style of
packaging meta-data:
* Use more maintainable syntax in templates. That is, more MKit macros,
line-based lists, etc.
* Use Markdown for LICENSE.
* Use normal case (don't YELL) in application name.
* Use only spaces to align spec file.
* Use version ranges for SemVer dependencies.
* Sort %files section.
* Use shorter version level (0.y vs 0.y.z) in ranges where possible
* Move MKit compatibility directive to bottom (which actually changes
the compatibility level to 0.0.24 as older MKit had a bug that
prevented seeing the directive near the bottom.)
Overview of changes:
* Excluded inigrep as well as saturnin itself from normal debugging mode
One has to call -D|--full-debug to see the gory inigrep/saturnin stuff.
Normal debug is supposed to be used for things relevant to
subcommand scripts.
* Moved to /usr
* Added --full-debug and -V to tab completion script
* Many code and packaging clean-ups
* Updated for Saturnin v0.4.7
* Updated for Shellfu v0.10.1
* Updated MKit to v0.0.24
They made sense when the script was bigger, now they delimit basically
the whole script. Also "built part" is not accurate since the part is
not built--it only happens to contain lot of macros.
Saturnin Shellfu module used to be embedded into the repo; now it lives
its own life (we already have it in dependencies). All the app needs is
meta-command and scripts.
Overview of changes:
* Fixed quoting when setting $SATURNIN_CONF_PATH
* Replaced complete.bash with skeletal version of itself
With reasonable version of mkit, the skeleton can be readily used
without any modifications.
* Applied first attempt to be more conformant with XDG standards
Saturnin-demo now uses XDG paths for cache, local data and config
data and does it in such a way that respects these values from
environment variables as prescribed by current XDG.
Note that not all paths described by XDG are used.
* Simplified Saturnin's mkit tokens
Another step to increase usability of this demo with as little
modifications as possible.
Turns out this is not good practice; the tokens are only used within the
process of building the application so there's no need to qualify them.
Having them qualified in fact adds unnecessary spam when syncing with
the template.