.\" -*- mode: troff; coding: utf-8 -*- .\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>. .ie n \{\ . ds C` "" . ds C' "" 'br\} .el\{\ . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "DH_ASSISTANT 1" .TH DH_ASSISTANT 1 2024-03-27 13.15.3 Debhelper .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH NAME dh_assistant \- tool for supporting debhelper tools and provide introspection .SH SYNOPSIS .IX Header "SYNOPSIS" \&\fBdh_assistant\fR \fR\f(BIcommand\fR\fB\fR [\fIadditional\ options\fR] .SH DESCRIPTION .IX Header "DESCRIPTION" \&\fBdh_assistant\fR is a debhelper program that provides introspection into the debhelper stack to assist third-party tools (e.g. linters) or third-party debhelper implementations not using the debhelper script API (e.g., because they are not written in Perl). .SH COMMANDS .IX Header "COMMANDS" The \fBdh_assistant\fR supports the following commands: .SS "active-compat-level (AJSON)" .IX Subsection "active-compat-level (AJSON)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBactive-compat-level\fR .PP Outputs information about which compat level the package is using. .PP For packages without valid debhelper compatibility information (whether missing, ambiguous, not supported or simply invalid), this command operates on a "best effort" basis and may abort when error instead of providing data. .PP The returned JSON dictionary contains the following key-value pairs: .IP active-compat-level 4 .IX Item "active-compat-level" The compat level that debhelper will be using. This is the same as \fBDH_COMPAT\fR when present or else \fBdeclared-compat-level\fR. This can be \fBnull\fR when no compat level can be detected. .IP declared-compat-level 4 .IX Item "declared-compat-level" The compat level that the package declared as its default compat level. This can be \fBnull\fR if the package does not declare any compat level at all. .IP declared-compat-level-source 4 .IX Item "declared-compat-level-source" Defines how the compat level was declared. This is null (for the same reason as \&\fBdeclared-compat-level\fR) or one of: .RS 4 .IP debian/compat 4 .IX Item "debian/compat" The compatibility level was declared in the first line \fIdebian/compat\fR file. .IP "X\-DH-Compat: " 4 .IX Item "X-DH-Compat: " The compatibility was declared in the \fIdebian/control\fR via a the \fBX\-DH-Compat\fR field. In the output, the \fBC\fR is replaced by the actual compatibility level. A full example value would be: .Sp .Vb 1 \& X\-DH\-Compat: 15 .Ve .IP "Build-Depends: debhelper-compat (= )" 4 .IX Item "Build-Depends: debhelper-compat (= )" The compatibility was declared in the \fIdebian/control\fR via a build dependency on the \&\fBdebhelper-compat (= )\fR package in the \fBBuild-Depends\fR field. In the output, the \fBC\fR is replaced by the actual compatibility level. A full example value would be: .Sp .Vb 1 \& Build\-Depends: debhelper\-compat (= 15) .Ve .RE .RS 4 .RE .SS "supported-compat-levels (AJSON, CRFA)" .IX Subsection "supported-compat-levels (AJSON, CRFA)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBsupported-compat-levels\fR .PP Outputs information about which compat levels, this build of debhelper knows about. .PP This command accepts no options or arguments. .SS "which-build-system (AJSON)" .IX Subsection "which-build-system (AJSON)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBwhich-build-system\fR [\fIbuild\ step\fR] [\fIbuild\ system\ options\fR] .PP Output information about which build system would be used for a particular build step. The build step must be one of \fBconfigure\fR, \fBbuild\fR, \fBtest\fR, \fBinstall\fR or \fBclean\fR and must be the first argument after \fBwhich-build-system\fR when provided. If omitted, it defaults to \fBconfigure\fR as it is the most reliable step to use auto-detection on in a clean source directory. Note that build steps do not always agree when using auto-detection \- particularly if the \fBconfigure\fR step has not been run. .PP Additionally, the \fBclean\fR step can also provide "surprising" results for builds that rely on a separate build directory. In such cases, debhelper will return the first build system that uses a separate build directory rather than the one build system that \fBconfigure\fR would detect. This is generally a cosmetic issue as both build systems are all basically a glorified \&\fBrm \-fr builddir\fR and more precise detection is functionally irrelevant as far as debhelper is concerned. .PP The option accepts all debhelper build system arguments \- i.e., options you can pass to all of the \fBdh_auto_*\fR commands plus (for the \fBinstall\fR step) the \fB\-\-destdir\fR option. These options affect the output and auto-detection in various ways. Passing \fB\-S\fR or \fB\-\-buildsystem\fR overrides the auto-detection (as it does for \fBdh_auto_*\fR) but it still provides introspection into the chosen build system. .PP Things that are useful to know about the output: .IP \(bu 4 The key \fBbuild-system\fR is the build system that would be used by debhelper for the given step (with the given options, debhelper compat level, environment variables and the given working directory). When \fB\-S\fR and \fB\-\-buildsystem\fR are omitted, this is the result of debhelper's auto-detection logic. .Sp The value is valid as a parameter for the \fB\-\-buildsystem\fR option. .Sp The special value \fBnone\fR is used to denote that no build system would be used. This value is not present in \fB\-\-list\fR parameter for the \fBdh_auto_*\fR commands, but since debhelper/12.9 the value is accepted for the \fB\-\-buildsystem\fR option. .Sp Note that auto-detection is subject to limitations in regards to third-party build systems. While debhelper \fIdoes\fR support auto-detecting some third-party build systems, they must be installed for the detection to work. If they are not installed, the detection logic silently skips that build system (often resulting in \fBbuild-system\fR being \fBnone\fR in the output). .IP \(bu 4 The \fBbuild-directory\fR and \fBbuildpath\fR values serve different but related purposes. The \&\fBbuild-directory\fR generally mirrors the \fB\-\-builddirectory\fR option where as \fBbuildpath\fR is the output directory that debhelper will use. Therefore the former will often be null when \fB\-\-builddirectory\fR has not been passed while the latter will generally not be null (except when \fBbuild-system\fR is \fBnone\fR). .IP \(bu 4 The \fBdest-directory\fR (\fB\-\-destdir\fR) is undefined for all build steps except the \fBinstall\fR build step (will be output as null or absent). For the same reason, \fB\-\-destdir\fR should only be passed for \fBinstall\fR build step. .Sp Note that if not specified, this value is currently null by default. .IP \(bu 4 The \fBparallel\fR value is subject to \fBDEB_BUILD_OPTIONS\fR. Notably, if that does not include the \fBparallel\fR keyword, then \fBparallel\fR field in the output will always be 1. .IP \(bu 4 Most fields in the output \fIcan\fR be null. Particular if there is no build system is detected (or when \fB\-\-buildsystem=none\fR). Additionally, many of the fields can be null even if there is a build system if the build system does not use/set/define that variable. .SS "detect-hook-targets (AJSON)" .IX Subsection "detect-hook-targets (AJSON)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBdetect-hook-targets\fR .PP Detects possible override targets and hook targets that \fBdh\fR\|(1) might use (provided that the relevant command is in the sequence). .PP The detection is based on scanning the rules file for any target that \fImight look\fR like a hook target and can therefore list targets that are in fact not hook targets (or are but will never be triggered for other reasons). .PP The detection uses a similar logic for scanning the rules file and is therefore subject to makefile conditionals (i.e., the truth value of makefile conditionals can change whether a hook target is visible in the output of this command). In theory, you would have to setup up the environment to look like it would during a build for getting the most accurate output. Though, a lot of packages will not have conditional hook targets, so the "out of the box" behaviour will work well in most cases. .PP The output looks something like this: .PP .Vb 10 \& { \& "commands\-not\-in\-path": [ \& "dh_foo" \& ], \& "hook\-targets": [ \& { \& "command": "dh_strip_nondeterminism", \& "is\-empty": true, \& "package\-section\-param": null, \& "filename": "debian/rules", \& "target\-name": "override_dh_strip_nondeterminism" \& }, \& { \& "command": "dh_foo", \& "is\-empty": false, \& "package\-section\-param": "\-a", \& "filename": "debian/rules", \& "target\-name": "override_dh_foo\-arch" \& } \& ] \& } .Ve .PP In more details: .IP commands-not-in-path 4 .IX Item "commands-not-in-path" This attribute lists all the commands related to hook targets, which \fBdh_assistant\fR could \fBnot\fR find in PATH. These are usually caused by either the command not being installed on the system where \fBdh_assistant\fR is run or by the command not existing at all. .Sp If you are using this command to verify an hook target is present, please double check that the command is spelled correctly. .IP hook-targets 4 .IX Item "hook-targets" List over hook targets found along with additional information about them. .RS 4 .IP command 4 .IX Item "command" Attribute that lists which command this hook target is related too. .IP target-name 4 .IX Item "target-name" The actual target name detected in the \fIdebian/rules\fR file. .IP is-empty 4 .IX Item "is-empty" A boolean that determines whether \fBdh\fR\|(1) will optimize the hook out at runtime (see "Completely empty targets" in \&\fBdh\fR\|(1)). Note that empty override targets will still cause \fBdh\fR\|(1) to skip the original command. .IP package-section-param 4 .IX Item "package-section-param" This attribute defines what package selection parameter should be passed to \fBdh_*\fR commands used in the hook target. It can either be \fB\-a\fR, \fB\-i\fR or (if no parameter should be used) \f(CW\*(C`null\*(C'\fR. .IP filename 4 .IX Item "filename" This attribute reports which file the target was found it. In most cases, this will always be "debian/rules" though in case of include files, the target could appear in an include file. Note this attribute is not super reliable as \fBmake\fR\|(1) only reports it for targets with a "recipe" (targets with commands inside them). When \fBmake\fR does not provide the filename, \fBdh_assistant\fR blindly assumes the filename is "debian/rules" (as overrides via includes is not a commonly used feature). .Sp Note this accuracy of this attribute is limited about what data \fBdh_assistant\fR can read out from the following command: .Sp .Vb 1 \& LC_ALL=C make \-Rrnpsf debian/rules debhelper\-fail\-me 2>/dev/null .Ve .RE .RS 4 .RE .PP This command accepts no options or arguments. .SS "detect-unknown-hook-targets (AJSON, LINT)" .IX Subsection "detect-unknown-hook-targets (AJSON, LINT)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBdetect-unknown-hook-targets\fR [\-\-output\-format=json] [command\-options] .PP Detects unknown and possibly misspelled override targets and hook targets in \fIdebian/rules\fR that will most likely not be used by \fBdh\fR\|(1). .PP This command differs from \fBdetect-hook-targets\fR subtly in the scope. The \fBdetect-hook-targets\fR will list all targets that looks like hook targets whether they are applicable or not. This command show all hook targets, for which a command cannot be found in any sequence. Accordingly, this command is better for linting purposes whereas \fBdetect-hook-targets\fR is better if you want to know which hook targets are present. All the limitations listed in \fBdetect-hook-targets\fR about scanning the rules file apply equally to this command. .PP This command will attempt will attempt to load any sequence add-on listed via build-dependencies and therefore these must be installed. Additional modules can be passed via \fB\-\-with\fR like with \&\fBdh\fR\|(1) as needed. .PP This command will also need one of the following perl modules to be available: Text::Levenshtein, Text::LevenshteinXS, Text::Levenshtein::XS. The first one can be installed via \fBapt install libtext-levenshtein-perl\fR. .PP The text output is intended for human consumption and should be self-explanatory. Since it is not stable, it will not be documented. The JSON output looks something like this: .PP .Vb 11 \& { \& "unknown\-hook\-targets": [ \& { \& "target\-name": "execute_before_dh_instlal", \& "filename": "debian/rules", \& "candidates": [ \& "execute_before_dh_install" \& ] \& } \& ] \& } .Ve .PP In more details: .IP unknown-hook-targets 4 .IX Item "unknown-hook-targets" List of all the unknown hook targets found along with additional information about them. .RS 4 .IP target-name 4 .IX Item "target-name" The actual target name detected in the file (usually \fIdebian/rules\fR). .IP filename 4 .IX Item "filename" This attribute reports which file the target was found it. In most cases, this will always be "debian/rules" though in case of include files, the target could appear in an include file. Note this attribute is not super reliable as \fBmake\fR\|(1) only reports it for targets with a "recipe" (targets with commands inside them). When \fBmake\fR does not provide the filename, \fBdh_assistant\fR blindly assumes the filename is "debian/rules" (as overrides via includes is not a commonly used feature). .Sp Note this accuracy of this attribute is limited about what data \fBdh_assistant\fR can read out from the following command: .Sp .Vb 1 \& LC_ALL=C make \-Rrnpsf debian/rules debhelper\-fail\-me 2>/dev/null .Ve .IP candidates 4 .IX Item "candidates" When not null and not empty, each element in this list are names for likely candidates for the "correct" name of this target. .IP filename 4 .IX Item "filename" .RE .RS 4 .RE .PD 0 .IP issues 4 .IX Item "issues" .PD If present, then it is a list of one or more reasons why this output is definitely incomplete. Each element in the list is an object with the following keys: .RS 4 .IP issue 4 .IX Item "issue" A key defining the issue. Currently, it is always \fBload-addon\fR, which signals that \fBdh_assistant\fR could not load the add-on listed in the \fBaddon\fR key. .Sp Parsers should assume new issue types may appear in the future. .IP addon 4 .IX Item "addon" If present, it defines the name of a \fBdh\fR sequence add-on that is related to the failure. .RE .RS 4 .RE .PP This command accepts the following options: .IP \fB\-\-output\-format=\fR\fIFORMAT\fR 4 .IX Item "--output-format=FORMAT" Request a certain type of output format. Valid values are \fBtext\fR or \fBjson\fR. .Sp The text format is intended for human consumption and may change between versions without any regard for machine consumption. If you want to use this command for machine consumption, please use the JSON format. .IP "\fB\-\-no\-linter\-exit\-code\fR, \fB\-\-linter\-exit\-code\fR" 4 .IX Item "--no-linter-exit-code, --linter-exit-code" These options control whether the command should exit with the linter exit code (2) or not (0) when an unknown target is found. By default, it uses the linter exit code when an unknown target is found. .IP "\fB\-\-with\fR \fIaddon\fR, \fB\-\-without\fR \fIaddon\fR" 4 .IX Item "--with addon, --without addon" These options behave the same as the \fBdh\fR\|(1) options with the same name. .SS "list-commands (RJSON)" .IX Subsection "list-commands (RJSON)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBlist-commands\fR [\-\-output\-format=json] [command\-options] .PP Load all \fBdh\fR sequence add-ons and extract a full list of all commands that will be invoked across all sequences. The command makes no attempt to filter out commands that will not be run due to override targets or due to certain sequences not being run (by \fBdh\fR or at all). .PP As the command will attempt to load all plugins, they must be installed. .PP The text output is intended for human consumption and should be self-explanatory. Since it is not stable, it will not be documented. The JSON output looks something like this: .PP .Vb 10 \& { \& "commands": [ \& { \& "command": "dh_auto_build" \& }, \& { \& "command": "dh_auto_clean" \& }, \& [... more commands listed here... ] \& ], \& "issues": [ \& { \& "issue": "load\-addon", \& "addon": "foo" \& } \& ] \& } .Ve .IP commands 4 .IX Item "commands" The top level key containing the list of all commands. Each element in the list are an object and can have the following keys: .RS 4 .IP command 4 .IX Item "command" The name of the command. .Sp While most commands are resolved via PATH, a sequence add-on could register a command via a full path (by passing the path search). If so, the command provided in this output will also use the full path. .RE .RS 4 .RE .IP issues 4 .IX Item "issues" If present, then it is a list of one or more reasons why this output is definitely incomplete. Each element in the list is an object with the following keys: .RS 4 .IP issue 4 .IX Item "issue" A key defining the issue. Currently, it is always \fBload-addon\fR, which signals that \fBdh_assistant\fR could not load the add-on listed in the \fBaddon\fR key. .Sp Parsers should assume new issue types may appear in the future. .IP addon 4 .IX Item "addon" If present, it defines the name of a \fBdh\fR sequence add-on that is related to the failure. .RE .RS 4 .RE .PP This command accepts the following options: .IP \fB\-\-output\-format=\fR\fIFORMAT\fR 4 .IX Item "--output-format=FORMAT" Request a certain type of output format. Valid values are \fBtext\fR or \fBjson\fR. .Sp The text format is intended for human consumption and may change between versions without any regard for machine consumption. If you want to use this command for machine consumption, please use the JSON format. .IP "\fB\-\-with\fR \fIaddon\fR, \fB\-\-without\fR \fIaddon\fR" 4 .IX Item "--with addon, --without addon" These options behave the same as the \fBdh\fR\|(1) options with the same name. .SS "list-guessed-dh-config-files (AJSON)" .IX Subsection "list-guessed-dh-config-files (AJSON)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBlist-guessed-dh-config-files\fR [command\-options] .PP Load all \fBdh\fR sequence add-ons, determine the full list of commands could be used by this source package and for each command used, then attempt to \fIguess\fR which "config files" these commands are interested in. .PP Note this command only guesses "per command config files". Standard global config files such as \fIdebian/control\fR, \fIdebian/rules\fR, and \fIdebian/compat\fR are not included in this output. .PP As the command name implies, the resulting output is not a full list (and will never be). The \fBdh_assistant\fR tool have to derive this from optional metadata that commands can choose to provide and \fBdh_assistant\fR has no means to validate that this metadata is up to date. .PP As the command will attempt to load all plugins, they must be installed. .PP The text output is intended for human consumption and should be self-explanatory. Since it is not stable, it will not be documented. The JSON output looks something like this: .PP .Vb 10 \& { \& "config\-files": [ \& { \& "commands": [ \& { \& "command": "dh_autoreconf_clean" \& } \& ], \& "file\-type": "pkgfile", \& "pkgfile": "autoreconf.before" \& }, \& { \& "commands": [ \& { \& "command": "dh_installgsettings" \& } \& ], \& "file\-type": "pkgfile", \& "pkgfile": "gsettings\-override" \& }, \& # [ ... more entries here ...] \& ], \& "issues": [ \& { \& "issue": "load\-addon", \& "addon": "foo" \& } \& ] \& } .Ve .IP config-files 4 .IX Item "config-files" The top level key containing the list of all config-files. Each element in the list are an object and can have the following keys: .RS 4 .IP file-type 4 .IX Item "file-type" The type of config file detected. At the time of writing, this will always be \fBpkgfile\fR. However, other values may appear in the future. .Sp The \fBpkgfile\fR key means that the config file is a \fBdebhelper pkgfile\fR (named after the \fBpkgfile\fR sub in Debian::Debhelper::Dh_Lib that locates the file). .IP pkgfile 4 .IX Item "pkgfile" When \fBfile-type\fR is \fBpkgfile\fR, this key defines the name stem of the \fBpkgfile\fR. An example, this will be \fBinstall\fR for \fBdh_install\fR\|(1)'s config file and \fBdocs\fR for \fBdh_installdocs\fR\|(1)'s config file. .Sp When \fBfile-type\fR is \fBnot\fR \fBpkgfile\fR, then this key will be absent. .Sp Typically names for these files are: .Sp .Vb 2 \& debian/PKGFILE \& debian/PACKAGE.PKGFILE .Ve .Sp However, there are more variants caused by \fB\-\-name\fR plus architecture specific suffixes. .IP internal 4 .IX Item "internal" This key may exist and any value for it is not standardized. Use at own peril. .Sp It used for document certain specific implementation details such as bug compatibility and may change as the situation changes. .IP commands 4 .IX Item "commands" This key will be a list with each element in it being an object with the following keys: .RS 4 .IP command 4 .IX Item "command" Name of the command that is interested in this config file. Multiple commands can be interested in the same config file. An example of this would be \fBdh_installinit\fR, \fBdh_installsystemd\fR and \fBdh_installtmpfiles\fR, which all reacts to (the now) deprecated \fBtmpfile\fR pkgfile. In the particular case, only one command reacts to the file for a given compat level (but that information is not available to \fBdh_assistant\fR and therefore is not available in this output either). .RE .RS 4 .RE .RE .RS 4 .RE .IP issues 4 .IX Item "issues" If present, then it is a list of one or more reasons why this output is definitely incomplete. Each element in the list is an object with the following keys: .RS 4 .IP issue 4 .IX Item "issue" A key defining the issue. Currently, it is always \fBload-addon\fR, which signals that \fBdh_assistant\fR could not load the add-on listed in the \fBaddon\fR key. .Sp Parsers should assume new issue types may appear in the future. .IP addon 4 .IX Item "addon" If present, it defines the name of a \fBdh\fR sequence add-on that is related to the failure. .RE .RS 4 .RE .PP This command accepts the following options: .IP "\fB\-\-with\fR \fIaddon\fR, \fB\-\-without\fR \fIaddon\fR" 4 .IX Item "--with addon, --without addon" These options behave the same as the \fBdh\fR\|(1) options with the same name. .SS "log-installed-files (BLD)" .IX Subsection "log-installed-files (BLD)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBlog-installed-files\fR \fB\-p\fR\f(BIpkg\fR \fI[\-\-on\-behalf\-of\-cmd=dh_foo]\fR \fBpath ...\fR .PP Mark one or more paths as installed for a given package. This is useful for telling \fBdh_missing\fR\|(1) that the paths have been installed manually. .PP The \fB\-\-on\-behalf\-of\-cmd\fR option can be used by third-party tools to have \fBdh_assistant\fR list them as the installer of the provided paths. The convention is to use the basename of the tool itself as its name (e.g. \fBdh_install\fR). .PP Please keep in mind that: .IP \(bu 4 \&\fBNo\fR glob or substitution expansion is done by \fBdh_assistant\fR on the provided paths. If you want to use globs, have the shell perform the expansion first. .IP \(bu 4 Paths must be given as relative to the source root directory (e.g., \fIdebian/tmp/...\fR) .IP \(bu 4 You \fIcan\fR provide a directory. If you do, the directory and anything recursively below it will be considered as installed. Note that it is fine to provide the directory even if paths inside of it has been excluded as long as the directory is fully "covered". .IP \(bu 4 Do not worry about providing the same filename twice in different invocations to \fBdh_assistant\fR due to \fB\-arch\fR / \&\fB\-indep\fR overrides. While it will be recorded multiple internally, \fBdh_missing\fR\|(1) will deduplicate when it parses the records. .PP Note this command only \fImarks\fR paths as installed. It does not actually install them \- the caller should ensure that the paths are in fact handled (or installed). .SS "restore-file-on-clean (BLD)" .IX Subsection "restore-file-on-clean (BLD)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBrestore-file-on-clean\fR \fBFILE ...\fR .PP This command will take a backup of listed files and tell \fBdh_clean\fR\|(1) to restore them when it runs. .PP Note that generally you do not need to restore modified files on clean. Often you can get away with just removing them if they are regenerated anyway (which is the most common case for files being modified during builds). Use this command when something taints a file and the build does not cope with the file being removed. .PP The file is stored in \fBdebian/.debhelper\fR. If you remove this directory manually without calling \&\fBdh_clean\fR\|(1) then your \fBdh_assistant\fR provided backup is gone permanently and the restore will never occur. At this point, only a version control system or another backup can restore the files. .PP The command has the following limitations: .IP "No thread-safety \- concurrency will corrupt the restore" 4 .IX Item "No thread-safety - concurrency will corrupt the restore" The command relies on updating an internal index and concurrent writes will cause it to be corrupt. .Sp While most \fBdh_*\fR commands does not use the underlying function, any of them could do so. Avoid running another \fBdh_*\fR command while \fBdh_assistant\fR processes this command (especially running multiple concurrent instances of \fBdh_assistant restore-file-on-clean\fR is asking for corruption!). .IP "Files only, not directories nor symlinks to files" 4 .IX Item "Files only, not directories nor symlinks to files" This command will only restore files; not directories or symlinks to files. It will reject any non-files. .Sp Additionally, if the directory containing the file is removed, the restore will fail (as \fBdebhelper\fR does not track the directory, it cannot restore it reliably). If this happens, you can do a \fBmkdir\fR to restore the directory and run \fBdh_clean\fR\|(1) again to get the files back. After that, consider what went wrong and whether you are using the correct tool(s). .IP "Strict file names" 4 .IX Item "Strict file names" All filenames must be relative to the package root (without using the \fB./\fR prefix). No hidden files (that is any file starting with a period \fB.\fR) and no version control directories (such as \fBCVS\fR). The checks are best effort. .Sp These checks are here to ensure you do not accidentally trash important data that would help you undo mistakes. .IP "Heavy duty" 4 .IX Item "Heavy duty" The command takes a \fBfull copy\fR of all files you pass it. This is fine for a handful of small files, which is the intended use-case. If you find yourself passing 10+ files or very large files, you might be applying a sledgehammer where you needed a different tool. .SS "supports (CFFA)" .IX Subsection "supports (CFFA)" \&\fBSynopsis\fR: \fBdh_assistant\fR \fBsupports\fR \fBCOMMAND\fR .PP This command is a scripting aid to programmatically determine whether \fBdh_assistant\fR knows about a given subcommand. Pass the name of a subcommand and this command will exit successfully if the subcommand was known and unsuccessfully otherwise. .SH "COMMAND TAGS" .IX Header "COMMAND TAGS" Most commands have one or more of the following "tags" associated with them. Their meaning is defined here. .IP AJSON 4 .IX Item "AJSON" The command always provides JSON output. See "JSON OUTPUT" for details. .IP OJSON 4 .IX Item "OJSON" The command *can* provide JSON output via \fB\-\-output\-format=json\fR, but does not do so by default. See "JSON OUTPUT" for details when using \fB\-\-output\-format=json\fR. .IP LINT 4 .IX Item "LINT" The command is or can be used for linting purposes. This command will exit with code 2 when an important issue is found. .Sp Note that commands may have options that redefine what is considered an "important" issue. .IP CRFA 4 .IX Item "CRFA" \&\fIMnemonic "Can be Run From Anywhere"\fR .Sp Most commands must be run inside a source package root directory (a directory containing \fIdebian/control\fR) because debhelper will need the package metadata to lookup the information. Any command with this tag are exempt from this requirement and is expected to work regardless of where they are run. .IP BLD 4 .IX Item "BLD" The command is intended to be used as a part of a package build. It may leave artifacts behind that will need a \fBdh_clean\fR\|(1) invocation to remove. .SH "JSON OUTPUT" .IX Header "JSON OUTPUT" Most commands uses JSON format as output. Consumers need to be aware that: .IP \(bu 4 Additional keys may be added at any time. For backwards compatibility, the absence of a key should in general be interpreted as null unless another default is documented or would be "obvious" for that case. .IP \(bu 4 Many keys can be null/undefined in special cases. As an example, some information may be unavailable when this command is run directly from the debhelper source (git repository). .PP The output will be prettified when stdout is detected as a terminal. If you need to pipe the output to a pager/file (etc.) and still want it prettified, please use an external JSON formatter. An example of this: .PP .Vb 1 \& dh_assistant supported\-compat\-levels | json_pp | less .Ve .SH "SEE ALSO" .IX Header "SEE ALSO" \&\fBdebhelper\fR\|(7) .PP This program is a part of debhelper.