Skip to content

Want to generate reference package assignments during build #3271

@jimklimov

Description

@jimklimov

NUT has (at least a stub of) reference documentation for files that belong to different packages, and how those depend on each other, grouping the built artifacts either by purpose, e.g. "nut-common" with user/group account definitions and shared system configs and directories, which is generally a dependency for all other packages to be installed on top of it in whatever mix is needed by a particular deployment, whether the "nut-server" side, or "nut-client" collection, or tools like nut-scanner and nut-conf, or some NUT development oriented files and scripts, or one of many "nut-driver*" programs grouped by their third-party dependencies to minimize the installed footprint by avoiding the packages a user has no need for (e.g. SNMP with USB-only UPSes), and somewhat orthogonally to that - documentation files for each such category (MAN and/or HTML rendering) which some OSes provide as a separate package or facet of one with the programs.

On the other hand, there are multiple operating systems and packaging methods which actually define the packaging recipe and manifest files to build a particular set of packages based on the current NUT configuration. Some technologies allow use of include files right away, for others the "hard-coded" lists have to be updated. Either way, for every added or renamed program, possibly placed differently in this or that distro, we are talking about updating a lot of files that must specify it. There is also a problem with simpler manifests using an asterisk in path names (instead of explicit file names) that several packages may end up delivering the same file, causing more storage use for the package files and possibly conflicts upon installation.

This is probably okay and even desired for OS-side packaging definitions (they want to say exactly what and where is delivered by a package build, and anything missing or extraneous to that is a bug that must be addressed by a package developer), but less useful for end-user and developer (and CI) builds of packages whose content is dictated rather by the choice of configure options and specific build environment capabilities at the time of build.

This issue proposes to help maintain the OS distro lists ("what changed since last NUT release?") and directly feed into ad-hoc package builds ("make a pkg of what I have configured here") by adding some way similar to make install for listing the resulting delivered files as assigned to this or that recommended package. It is then up to specific (reference) packaging definitions and recipes to transform (e.g. add debian/tmp/ prefixes) and include one or more such lists as contents of a package, and to list which packages overall are actually built today for this configuration (ultimately which are dependencies for a nut umbrella package).

This also allows to check (in CI) whether we deliver any files for which we missed a listing like this. or if we list any file that for some reason was not installed. Such files should not however be included in Git (and possibly not even in dist archives) as they are configuration and platform dependent.

Technologically this can be probably integrated with existing automake definitions like *_PROGRAMS, *_SCRIPTS, *_data, *_LTLIBRARIES etc. so files which go into those would be first listed in newly minted make variables, and it is those variables that are assigned to this or that recommended package, and manifests can be generated by a recipe. Maybe something can be hacked up with disthook etc. support too, or (worse) tapping into the Makefile code, recipes and variables generated by autotools, to minimize work on NUT recipe side - thinking of dash-to-underscore conversions in prog/lib names to produce make variables.

Metadata

Metadata

Assignees

No one assigned

    Labels

    CIEntries related to continuous integration infrastructure (here CI = tools + scripts + recipes)documentationenhancementpackaging

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions