1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
____ ____ _ _ _____ _ _ ____ _____ _ ___
| _ \| _ \| | | |_ _| | \ | |/ ___| | ___/ \ / _ \ ___
| | | | |_) | | | | | |_____| \| | | _ | |_ / _ \| | | / __|
| |_| | __/| |_| | | |_____| |\ | |_| | | _/ ___ \ |_| \__ \
|____/|_| \___/ |_| |_| \_|\____| |_|/_/ \_\__\_\___/
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.
|
