FAQ

    ____  ____  _   _ _____     _   _  ____            _____ _    ___
   |  _ \|  _ \| | | |_   _|   | \ | |/ ___|          |  ___/ \  / _ \ ___
   | | | | |_) | | | | | |_____|  \| | |  _           | |_ / _ \| | | / __|
   | |_| |  __/| |_| | | |_____| |\  | |_| |          |  _/ ___ \ |_| \__ \
   |____/|_|    \___/  |_|     |_| \_|\____|          |_|/_/   \_\__\_\___/


 1) So, what's the big deal, anyway?

   Well, yeah, good question. dput works great, and all the authors of
   dput-ng really love dput a lot. So much, in fact, that we've decided
   to maintain 100% compatibility with the flags, config files and expected
   behavior of the tool.

   The whole idea here is that dput is starting to get a bit too subject
   to bitrot, and new features are hard to implement. Moreover, adding new
   stuff has to happen at the dput level, which is a pain for people
   who support non-standard stuff.

   We have a spiffy new "plugin" system, where plugins can be in their own
   package (very far away from dput's) and still work famously.

 2) So, what's all this plugin nonsense about?

   All uploaders (stuff like sftp, scp, local, ftp, http) are implemented as
   "uploaders". They're registered via .json files, which declare the import
   path to the class -- such as `dput.uploaders.sftp.SFTPUploader`. This allows
   uploaders, hooks (they work just like uploaders!) to be run from dput-ng
   even if they're outside dput-ng's package (so, nothing stops you from
   writing `foopackage.barmodule.BazUploader` or `kruft.fooChecker` and using
   them when you need to).

   We think this will result in cool new hooks (since uploaders are a bit of
   work) being written to better check packages to be uploaded before they go
   too far :)

3) Is dput-ng compatible with dput configuration files?

    Short answer: Yes!
    Long answer: Well, mostly. We've chosen to re-define deprecated / outdated
                 things. You shouldn't notice any changes, except for users
                 of `run_dinstall'. You should also be aware that there are
                 some *new* configuration files, by default, in /etc/dput.d/
                 and ~/.dput.d/. These config files help define new features
                 and checker behavior.

4) Where does dput compatibility end?

    We attempted to make the binary look and feel as close to the original as
    we could muster -- as well as files it produces (.upload files, etc).

    Any issues with the interface's arguments are taken very seriously, and
    (with minor and documented exception) should be fixed very quickly.

5) How to make my own profile?

    Cool! So, profiles are not unlike dput.cf blocks, but the define the
    behavior of dput-ng a bit more exactly & in a fragmented way.

    All new config files are in JSON, and have similar override behavior to
    global / local dput.cf files.

    All you have to do is place a new profile in ~/.dput.d/profiles/ (or,
    for more the one user / distributing it -- /etc/dput.d/profiles) which
    looks similar to:

    $ cat ~/.dput.d/profiles/personal-archive.json
    {
        "name": "My Personal Archive",
        "+hooks": [
            "lintian"
        ],
        "interface": "cli"
    }

    You can read more about profiles, and the config files in the
    documentation.

6) Hey, I can't run dput -H -p or dput -p -H they way I think it should!

    well, try it with plain ole' dput :)

    Anyway, those arguments are a bit of a special case & for debugging. All
    the "short" flags can't be used together -- flags like "-v", "-H", or "-p"
    shouldn't be used together anyway.