Libyal

libyal is an umbrealla name for a number of projects providing libraries and/or utilities pertaining to forensic analysis of files, including but not limited to those generated by Microsoft environments.

Notes from and for openSUSE developers

• Project state
  • libyal consideres most of their creations to be unstable/alpha/beta, none of the component libs are stable.
  • libyal is not conducive to contributions, citing e.g. lack of time, or the beta state and that things "will change anyway" (but which won't happen in a timely fashion), or they don't see a usecase
    → Don't bother
  • There is no ABI management, citing the beta state.
    → Marked all libs in openSUSE with force-added symvers.
  • There are no curated changelogs ("NEWS"-file like prose) being produced; the git commit summaries are of bad quality too (same summary over and over again).
    → Situation conveyed through openSUSE changelog to end-users.
  • Upstream dis-recommends shared libraries, citing beta stage, and dis-recommends unbundling. At the same time, contradicts itself because the libraries are built in shared fashion by default, and system libs from /usr are reused when found.
    → Good enough for openSUSE. Shared builds and systemlib reuse is exactly what we want.
  • Cadence of releases (and/or git tags) is good in some subprojects and nonexistant in others
    → Maintainers for security:forensics may decide to use a git snapshot if deemed useful
• Contents of source distribution
  • Release tarballs bundle the source code for dependencies.
    → Does not affect openSUSE.
  • Git snapshots do not bundle dependencies.
    → Normal Git behavior, so no one to blame. Since openSUSE has system libs to reuse, the build does not need manual extra source bundling.
  • The git repositories do not use git submodule but a custom script, synclibs.sh. It's probably because git-submodule is not expresisve enough to do the file substitutions that synclibs.sh wants to do. Therefore, not using submodules appears legit.
  • configure.ac and Makefile.am contain a few lines that reference the locations of bundled code. git snapshots either need to pre-run synclibs.sh, or have AC_CONFIG_FILES lines removed.
    → openSUSE is mostly on release tarballs now; a few packages that still use _service are removing AC_CONFIG_FILES lines to let the autoreconf command succeed, because we cannot run synclibs.sh from _service, _service is not made for it.
  • When synclibs.sh is used (by upstream or anyone else), it pulls the most recent versions of dependencies. This suggests that a release tarball like libcdatetime-20220104 is only guaranteed to work with a dependency's most recent tag at the time, libcfile-20220101, but not necessarily libcfile-20210512.
    → The BuildRequires: lines are bumped accordingly during specfile updates.
• Versioning scheme
  • Subprojects are using YYYYMMDD, both for the git tags, github releases as well as the AC_INIT line in configure.ac.
    → YYYYMMDD it is for the version field of openSUSE packages. YMD has been used for plenty of years by now, and thanks to the eternal beta state, no changes in versioning scheme are currently anticipated by openSUSE maintainers.
  • The AC_INIT-provided version increases not only at release time, but also inbetween (i.e. as part of certain git commits). When command-line utilities are run and asked to self-report their version, the AC_INIT number is the one printed. [This behavior is proper.]
  • Does an AC_INIT version bump constitute a release? What should a distro use for the Version: field of the .spec file when using a Git snapshot as a base? Opinions differ.
    → openSUSE has been using the number from AC_INIT even if it is not a release tarball.
• Build procedure
  • The specfiles' BuildRequires lines are derived from the AC_CONFIG_FILES lines of libraries in configure.ac. This is a bit more than strictly needed for an all-shared build, but it's less work than figuring out from the final rpms which libs got used and which did not.
  • When building from git newer than approximately 20220101, a somewhat recent gettext-tools (0.21) is needed.
  • Out-of-tree support is not working, causing our foreach-python build loop to perform installs outside of the rpm %install section.
  • grep ' local' config.log && exit 1 is used to check that all dependencies were found in system libraries, not $PWD. The appearance of local does not always mean that bundled libs are used; in a case in libmodi for example it's the indicator for a disabled feature instead (possibly erroneously disabled by our build).
  • The %{python_expand # ...} magic collapses whitespace(!), which is why there is grep ' local' in the python-ish specfiles and just grep ' local' in the non-python ones.