Overview of changes:
* Split to core+module package
The package now demonstrates a slightly more complex (but more
useful) distribution model, when part of functionality is also
exposed as public API via Shellfu/Bash module.
* Fixed PRETTY_DEBUG_EXCLUDE not being applied
* Improved and fixed packaging meta-data
* Codebase maintenance
Split saturnin-demo to a double-package distribution, where one package
provides core saturnin-demo with its subcommands and the other provides
a Shellfu/Bash module saturnin_demo_greet.sh used by the first one.
Overview of changes:
* Removed SHELLFU_PATH from default setup
People are encouraged to put Shellfu modules to standard paths
anyway (where they can be seen by sfdoc), so this is not very
useful. We better get rid of it, taking another (path-related,
ie. unreliable) token out of mkit.ini. There's always option
of modifying app.skel or re-setting the path dynamically (from
sub-command or by a wrapper), if someone is so ashamed of their module
(but don't be!).
* Hardcoded default name of help file
Removes the one token that was missing in mkit.ini anyway, causing
false ugly errors to be thrown at real users. Again, if people can't
really use that name, they can alwas modify (or wrap) app.skel.
* app.skel now respects SATURNIN_CONF_PATH from environment.
Ie. tests should work even with v0.4.9+
* Moved app.skel right under src
There's virtually never anything else there.
* Added example meta help file
* Simplified and cleaned up mkit.ini
* Removed unnecessary override in %check
* Updated MKit to v0.0.25
SHELLFU_PATH brings more harm than good; developers are encouraged to
put their private modules to regular shellfu path (in most cases
/usr/share/shellfu/include-*) and use SHELLFU_PATH only for testing.
It's a bit simpler (gets rid of one whole token) and has the advantage
of exposing the library to sfdoc.
Overview of changes:
* Added build-time tests
Saturnin Demo now demonstrates how to add tests using TFKit and
enable them on both Fedora and Debian. (This means dependency bump
to Saturnin 0.4.8, since overriding SATURNIN_CONF_PATH was not
available, which made config-related tests hard in staged
installations.)
* Enabled overriding path variables in launcher
Launcher used to hard-code all environment variables. This made
testing in staged installations hard.
* Updated meta-data and templates
An amount of smaller changes has been done to improve readability,
maintainability and overall looks of packaging meta-data.
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
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.