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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
<html>
<head>
<title>PackageKit</title>
<link rel="stylesheet" href="style.css" type="text/css" media="screen"/></center>
</head>
<body>
<table align="center" class="title">
<tr>
<td><center><img src="img/packagekit.png"/></center></td>
<td width="95%" valign="middle"><p class="title">Screenshots</p></td>
<td><center><img src="img/packagekit.png"/></center></td>
</tr>
</table>
<p>Back to the <a href="index.html">main page</a></p>
<h1>Frequently asked questions</h1>
<h3>How complete are the backends?</h3>
<h4>Methods</h4>
<pre>
| conary | yum | apt | box | alpm | smart | pisi |
--------------------------------------------------------------------
resolve | X | X | | X | | X | X |
refresh-cache | X | X | X | X | | X | X |
\--force | | | | | | | |
get-updates | X | X | | X | | X | X |
update-system | X | X | | X | | X | X |
search-name | X | X | X | X | X | X | X |
search-details | | X | X | X | | X | X |
search-file | | X | | X | | | X |
search-group | | X | | | | | X |
install-package | X | X | | X | X | X | X |
install-file | | X | | X | | X | X |
remove-package | X | X | | X | X | X | X |
update-package | X | X | | X | | X | X |
get-depends | | X | | X | | X | X |
\--recursive | | | | | | | |
get-requires | X | X | | X | | | X |
\--recursive | | | | | | | |
get-description | X | X | X | X | | X | X |
get-files | X | X | | X | | X | X |
get-update-detail | | X | | | | | |
get-repo-list | | X | | X | X | X | X |
repo-enable | | X | | X | | X | |
repo-set-data | | X | | X | | | X |
cancel-transaction| X | X | | | | | X |
</pre>
<h4>Filters</h4>
<pre>
| conary | yum | apt | box | alpm | smart | pisi |
--------------------------------------------------------------------
installed | X | X | X | X | X | X | X |
development | | X | X | X | | | |
gui | | X | X | X | | | X |
</pre>
<h3>Why doesn't PackageKit work with SELinux?</h3>
<p>
<code>packagekitd</code> is not recognized by SELinux yet.
Until the policy is fixed to handle system activation, you'll have
to run in permissive mode, rather than enforcing.
</p>
<h3>What if the backend package manager doesn't support percentage updates?</h3>
<p>
You don't have to have a backend that supports percentage updates.
If you don't know the progress, just emit NoPercentageUpdates and then the UI
should just do the right thing and spin backwards and forwards.
</p>
<h3>Why are the remaining times sometimes not present or wildly wrong?</h3>
<p>
The remaining time to completion of the transaction is calculated using an
average time of the time between percentage updates points, extrapolated to 100%.
This means that backends that give accurate and frequent percentage-changed
signals will get accurate times.
</p>
<p>
If a backend updates the percentage using very course updates
(e.g. 20%, 40%, 60%, 80%, 100%) then the remaining time algorithm will not
perform well.
Similarly, if the duration of 0% to 50% takes 2 minutes and 50% to 100% takes
10 minutes then at first the time will be reported under the true time to
completion.
It is up to the backends to map the transaction progress to fine-granularity
accurate percentage updates, at least as best as possible.
</p>
<h3>With all the differences between backends, how will PackageKit support all the different options?</h3>
<p>
Backends don't have to support all options of all methods.
Just set an error and return false if not implemented.
</p>
<h3>But error codes are different on each backend?</h3>
<p>
Error codes have to be standardized so they can be localized.
The error detail field can just be the untranslatable output.
If you are creating a backend and you need another error enum, mention it
and we can add it to the supported list.
</p>
<h3>How will PackageKit handle installation an application that needs user interaction?</h3>
<p>
Upgrading, installing or removing packages <b>has to be 100% silent</b>.
</p>
<p>
The user cannot be prompted for questions "set applet setuid?" as these will
not be handled in PackageKit.
The backend should do the right thing, as these messages mean very little to
the average user and cannot be translated.
</p>
<h3>Does PackageKit replace up2date?</h3>
<p>
PackageKit does not replace up2date.
PackageKit is a way for users to interact with the packaging system, not for an
administrator to install software on remote machines.
</p>
<h3>Is PackageKit a system daemon, always running and using resources?</h3>
<p>
PackageKit is not yet another system daemon.
It quits when not doing anything, and only starts when something wants
information or a task completed.
</p>
<h3>How does PackageKit handle dependencies?</h3>
<p>
PackageKit <b>does not do</b> dependency resolution.
This problem has already been solved by the backend systems and we don't really
want to re-invent the wheel.
</p>
<p>
PackageKit does not have the fine-grained API to do everything.
For instance, synaptic should still use libapt as can do much more than can be
provided by PackageKit.
</p>
<h3>Does PackageKit replace the Red Carpet service?</h3>
<p>
PackageKit is not a replacement to red carpet.
Red carpet was really great and years ahead of it's time, but tried to do
everything package related on the system, and moved onto the enterprise
centralized management model.
Although cool, this latter point made things too political in my opinion.
</p>
<h3>How fast is PackageKit?</h3>
<p>
PackageKit is really fast.
It takes about 1 second to search for installed and available packages
with "power" in the description - no blocking of the UI happens at all as it's
all asynchronous.
All the applications start instantly with no root password needed at startup.
</p>
<h3>How does PackageKit work with multiple users?</h3>
<p>
PackageKit is designed from the ground up to work with fast user switching and
logging in and out of sessions during upgrades.
You can start a system upgrade, log out, log in as another user, and be notified
when the upgrade is complete, all without risking your rpmdb.
</p>
<h3>Can users still use their normal package managers and backends, such as Yum, APT or Conary?</h3>
<p>
PackageKit does not stop you using the low level tools yourself.
You can use rpm and yum or dpkg and apt when PK is inactive (99.999% of the time)
when you really need some command line love.
No more fighting over <code>yum</code>, <code>yum-updatesd</code>,
<code>pup</code> and <code>pirut</code>.
</p>
<h3>Is there an organization or corporation sponsoring development of PackageKit?</h3>
<p>
PackageKit is not sponsored by anyone.
Whilst interning at Red Hat I spent a few days on the API and some UI designs,
but all the coding is done in my free time.
</p>
<p>Back to the <a href="index.html">main page</a></p>
</body>
</html>
|
