-
Notifications
You must be signed in to change notification settings - Fork 5
/
FUTURE
133 lines (97 loc) · 5.27 KB
/
FUTURE
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
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
New features for the Hildon Application Manager
===============================================
* Fix the workaround pushed in commit 82b8b2 [dkedves & vjaquez]
Before the HildonStackableWindow only one HildonWindow existed, and all
the interaction flows started and ended in this window. But with the stackable
ones, the end of the interaction may end in another stackable window. The
workaround avoids the assertion raised when the current window is different
of the window what started in the interaction, using (hackishly) the last
pointer in the dialogue stack, instead of the current window.
IMO, the correct way to fix this is to AVOID the creation of new stackable
windows when an interaction flow is ongoing. [vjaquez]
* New hard buttons logic as in the spec. [vjaquez]
* Enable the user edit the package catalogues name.
* Complete port to new Fremantle APIs [vjaquez]
- update-notifier.c: alarm API.
- New widgets.
- New I18N strings.
* Try to get rid of the legal notice as much as possible [mvo]
Right now, the legal notice dialog is shown whenever a package from a
non-certified repository is installed. It might be more educational
to only show that notice when a non-certified repository is added or
enabled.
* Better handling and reporting of dependency and conflict issues. [mvo]
[DELAYED]
We need to get better at explaining the reasons why a given operation
can not be performed so that the user has a chance of taking
corrective actions.
Also, since we now have a visible package that represents the
operating system, we can be more agressive with making changes to
invisible packages: the operating system package will make sure (via
its dependencies) that we don't kill the device by accidentally
uninstalling or upgrading important packages.
The general principle that this feature aims to implement is that the
user-visible packages are managed completely manually by the user, and
the user-invisible packages are managed completely automatically.
Thus, the general behavior of the Application Manager should be the
following:
1 When the user requests to install or remove a package, the AM will
plan to do any necessary (and possible) changes to all the packages
to satisfy the request of the user. These changes can include
installing additional packages, removing already installed
packages, or upgrading installed packages to a newer version.
The AM should try at least as hard as apt-get to find a solution,
but it should favor upgrading over removing.
For example, instead of removing the OS meta package in order to
upgrade some invisible packages, it should prefer to upgrade the OS
meta package (and pull in the complete OS update).
2 Once a solution has been found, and it requires changes to user
visible packages, the user has to confirm these changes.
3 When no solution has been found, the only reasons for this can be
that the OS package would need to be removed, or that packages are
needed that are not available from any repository. This can be
explained easily, I'd assume. We should probably not even list the
individual packages that are missing, but just say that the
catalogues are broken.
The following steps might be appropriate:
- Investigate which algorithms apt-get and aptitude use for "install
<pkg>" and "remove <pkg>" and make them available in the apt-worker
(preferably aptitudes). Don't remove the existing algorithms.
- Add a red-pill setting that makes the apt-worker use those
algorithms.
- Tune the algorithms to favor upgrading over removal, as explained
under point 1 above.
- Add suitable problem detection and reporting algorithms that
implement points 1 and 2 from above. But instead of letting the
user confirm the planned changes to visible packages, we just report
these changes as errors, or do them automatically:
- If a visible package A would be removed and the user is doing a
"uninstall B" operation, we report "B is needed by A."
- If a visible package A would be removed and the user is doing a
"install B" operation, we report "B conflicts with A."
- If a visible package A would be newly installed or upgraded and
the user is doing a "install B" operation, and package A is not
the OS, we just do the upgrade.
- If package A from the last paragraph is the OS, we report "B needs
A to be installed first".
- If a visible package A would be newly installed or upgraded and
the user is doing a "uninstall B" operation, we report "B is
needed by A".
The reports should always include the respective versions of the
packages.
- Experiment! Make a decision whether we can ship with these
algorithms enabled by default or whether we can get the next step
done as well:
- Show the thing to the UI people so that we can come up with the
right way to do it: letting users confirm the changes to the visible
packages.
* Unify configuration by having one directory for dropping off xexp
files. [mvo, config-cleanup]
[DELAYED]
We should implement a unified handling of settings. Each setting has
up to four values: user value, system value, variant value, and
builtin value. These four values are merged according to the type of
the setting. All values except the builtin value can be unset.
* Implement Maemo-Upgrade-Only-From [mvo]
[DELAYED]
Details later.