NAME¶

dput - configuration file format for dput-ng

DESCRIPTION¶

dput supports two configuration file formats. The old-style configuration format was originally introduced by dput and is described in dput.cf(5). This manpage describes new-style configuration files only. All details are covered in in </usr/share/doc/dput-ng/html/reference/configs.html> which is available in the dput-ng-doc package.

FILES AND FORMAT¶

Upload targets are configured using JSON as described in RFC 4627. In a nutshell, dput configuration allows insignificant whitespace before or after any type statement. Each upload profile is stored in its own file and is represented as a pair of curly brackets surrounding name/value pairs described below. Both, name and values are strings. A single colon separates the name from the value. A string begins and ends with quotation marks and may be escaped. Booleans are either true or false (mind these are not surrounded by quotation marks).

Some keys names are accepting lists as possible value. A list is represented as square brackets surrounding zero or more values, separated by commas.

dput reads, in order, these directories:

Moreover, old-style configuration files are parsed and read. See READING TRADITIONAL CONFIGURATION FILES below. In general, packages are installing pre-defined defaults for popular upload targets to /usr/share/dput-ng/profiles/. System administrators who wish to override or create a new system-wide and shared target for many users may choose /etc/dput.d/profiles. Finally, local targets may be written to ~/.dput.d/profiles for personal upload targets.

Within each configuration directory, there may be another tier of configuration directories. There, these actual configuration directories may exist:

Moreover, these directories can exist and are documented here for the sake of completeness. However, users typically do not need to touch these unless you are developing or customizing existing plug-ins to dput or dcut

By default all configuration file locations are parsed, and overlaid in a additive manner. This way both, entire profiles and actual settings within a profile is inherited from any parent location defining a key within the current scope. Details are explained in the INHERITANCE OF KEYS section.

PROFILES¶

Profiles are indexed as <profile name>.json within the profiles/ configuration directory. Every profile may define these keys. Optionally a profile called DEFAULT.json can be defined as a superset of all existing profiles. Any other profile will inherit values from this profile. For a finer grained control see meta keyword and META-CLASSES below.

Following is an example configuration for a local upload profile, named "localhost.json".

{


    "+hooks": [


        "lintian"


    ],


    "-hooks": [


        "gpg"


    ],


    "incoming": "~/incoming",


    "meta": "debian",


    "method": "local",


    "run_lintian": true
}

Supported keys are:

allow_dcut (boolean)

allow_unsigned_uploads (boolean)

allowed_distributions (string)

default_host_main (string)

default_keyid (string)

full_upload_log (boolean)

fqdn (string)

distributions (string)

hash (string)

hooks (list of string)

interface (string)

incoming (string)

method (string)

login (string)

meta (list of string)

passive_ftp (boolean)

post_upload_command (string)

pre_upload_command (string)

run_lintian (boolean)

READING TRADITIONAL CONFIGURATION FILES¶

As outlined initially, dput reads and parses traditional INI style configuration files. It’s format is documented in dput.cf(5). These files are deprecated, but for the time being read and parsed. We encourage the removal of these global and local configuration files entirely.

Having that said, when in place old-style configuration files will overrule new style files, to preserve a possibly modified legacy behavior. That means, in order configuration values are inherited and keys are successively overwritten in this order:

This means, old-style configuration files always take relative precedence when installed. Use them with caution.

INHERITANCE OF KEYS¶

By default, keys will override any previously defined value. However, as a special case, there are three operators (=, + and -) that may be prefixed to names to merge with existing inherited values. This is beneficial when a profile wishes to add or remove values from an existing key which accepts lists of values. This is mostly useful to hooks which may want to extend an existing profile key that is inheriting values via it’s meta-class or parent.

{


    "hooks": [


        "gpg",


        "lintian"


    ]
}

{


    "hooks": [


        "checksum",


    ]
}

{


    "-hooks": [


        "lintian"


    ]


    "meta": [


            "my-defaults"


    ]
}

HOOKS¶

Hooks are pre- or post-uupload checks, They are pluggable components running before or after the upload of a package. Whether they run before or after the upload is determined by the JSON definition of a hook. That is an implementation detail the user typically does not need to worry about.

FILES¶

/usr/share/dput-ng/
/etc/dput.d/
~/.dput.d/

AUTHOR¶

dput-ng was originally written by Arno Töll <arno(a)debian.org> and Paul Richard I by the Grace of God of the United Kingdom of Debian and Ubuntu and of his other realms and territories King Head of the Fluxbox Window Manager Defender of the Faith Tagliamonte <paultag(a)debian.org>.

RESOURCES¶

RFC 4627, /usr/share/doc/dput-ng/html/reference/, dput(1), dcut(1), dcut(1)