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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
General:
* The ConfModule should not return the backup return code, ever, if
the confmodule it talks to has not indicated it has that capability.
* Get rid of the horrendous fd #3 hack in /usr/share/debconf/confmodule.
Unfortuantly, many packages probably depend on the hack. Options are to
find all such packages (by examining/auditing all packages that use
debconf), to come up with a new shell interface that is so much cooler
people will want to migrate to it, and make it not use the hack,
or to decide with Wichert that debconf should not ursurp stdin/out.
* Should be able to jump to debconf config when debconf is interacting with
the user.
* Regression tests.
* I need to implement the container template type. That's gonna be fun..
* Something I see frequently is a select list that needs lots of explination
for each option. It'd be neat if the explination could be added as a
parallell list with the select list, to keep the actual tokens that the
confmodule script gets back short. See modconf for how such a list could
display in whiptail.
* Darxus <darxus@Op.Net>
> I will probably leave debconf set to ask me every question for quite some
> time. But it would be nice, in addition the "yes" & "no" buttons, to have
> a "don't ask me again" checkbox, so next time it'll just used the stored
> answer.
Dialog frontend couldn't support this, but the rest could.
* Add a dbdriver format module that understands debconf-show output;
then you can pipe that into a ssh to a remote host and use
DEBCONF_DB_OVERIDE and fun stuff like that.
Protocol and spec revisions:
* Expose a way to iterate over questions; this would allow a UI independant
database browser to be easily written.
* Document the behavior of the seen flag when backing up in the same config
script run. (Tausq?)
* Get rid of notes, that data type is too prone to abuse; error is better.
Database:
* The division between Debconf::Config and Debconf::Db still needs thought.
They both call each other, but worse, Debconf::Db->load needs to be
called in dpkg-preconfigure and others before Debconf::Config->blah can
be used, which is unintuitive.
* There's also the Force-Flag-Seen thing, which is really a more generic
forcing of any given flag to any vale, and should expand to forcing any
field to a value too, I'd think. Perhaps it should be an overlaid
database really? Yes, I think so..
* Regression tests!
* The Backup driver cannot deal with situations where the db already has
stuff and the copy does not. Perhaps it should copy items whole from db
to copy if they do not already exist in the copy and an operation is done
to them?
* Debconf does not try to deal with things that were not passwords becoming
passwords. They stay in config.dat, world-readable. I'm not sure it _can_
detect this and move them to passwords.dat.
* PackageDir dbdriver needs testing, and needs to become used by default..
* Hmm, as a slight mod to PackageDir, it just might be possible to use
/var/lib/dpkg/info/*.templates as a packagedir database. The 822 module
does not currently handle the word-wrapped descriptions in there, and
it'd sorta have to be read-only and stacked under another db or something
to record owner info though. The overlying db would need to get copies of
templates if they got 2 owners, so the package they're in doesn't leave
the other owner stranded. Still, this would easily save 1 mb on most
debian installs, so I really should pursue it.
Noninteractive frontend:
* Just because it's noninteractive doesn't mean it can't output to the
console. I think it should do so, at least for errors (in addition to
mailing them). That way if an error is displayed and the package install
fails you don't just see it dying, you immediately see why.
Readline frontend:
* It might be better in terse mode to not print out the list of choices for
a select list, and instead rely on them using tab completion. However,
for this to be usable, it would need to ditch the numbered shortcuts in
this case, neither listing them in tab completion nor making them show up
as defaults in the prompt.
Dialog frontend:
* It'd be nice if the Dialog stuff could catch text that was to be
displayed that is in the same block, buffer it, and display it up at the top
when it prompts for an input that is in the same block.
Gnome frontend:
* Make it use a multiselect box instead of all the check boxes
* Add support for blocks and containers, both of which should let multiple
questions be grouped together in nice ways on the screen.
* It seems that text elements hang around on each page displayed after the
one they should be on. Actually, the Elements are not hanging around, but
the gtk label widgets are, and I don't know why.
Kde frontend:
* Improve error handling when debconf-kde-helper terminates unexpectedly.
Web based frontend:
* Well, a little security would be nice! It only allows connections
from localhost, but even that isn't good enough at all.
* Passwords are completly insecure.
* It can support blocks, so add them. I guess they could be used for
arranging questions into tables or something.
* It should have a config screen. In it, you configure the frontend itself.
One option would be to make it be in "quiet" mode -- this would make it
not display extended descriptions, just provide links them. Another thing
to configure would be what priority of questions it is displaying.
|
