![]() |
Frequently Asked Questions |
![]() |
Back to the main page
Backends do not have to be complete when they are added to PackageKit. If a feature is not present then it is hidden in the UI, which will explain why on some distributions the client tools look a little different to other distributions. You can see the latest feature matrix here.
No, as they are a potential security problem. The issues are as follows:
So what's the solution? Using a standard $vendor-release.rpm
or .deb
you can ship the standard repo or source with a signed GPG key.
Quoting Sebastian Heinlein, Allowing to easily add third party repositories and install third party software without a certification infrastructure is like opening the gates to hell. Most user just don't have got the technical understanding to handle this well.
gpk-application
and pkcon
do not work!GTK+ tools should not be run as the root user, PERIOD. Any GTK+ program run as the root user is a massive security hole -- GTK+ just isn't designed with this in mind. There are numerous attack vectors when running as root, and programs shouldn't do such insane and insecure things.
Please see the GTK+ explanation for more rationale.
PackageKit runs a process packagekitd
that is a daemon that runs per-system.
The daemon lets you schedule transactions using either the raw
DBUS methods, or using libpackagekit.
The transactions are very fine grained, so an application would have to manage
the transaction process itself.
This would mean handling the EULA and GPG callbacks in each application. This is less than ideal.
For this reason, a session helper is provided by the gpk-update-icon
process which
basically makes all the complexity go away; it handles all the GPG key authentication and
EULA agreements, and also works with Seahorse and GConf to give some of the settings session persistence.
Using the session service is also designed to be synchronous, which means you can send the DBUS call
and just wait for the result, rather than managing callbacks to update custom GUIs.
The session helper therefore depends on the shared code in gpk-update-icon
, but
because this is implemented as a DBUS service, can be coded as a QObject for KDE or a simpler
object for XFCE or EFL.
If you want full integration using
custom dialogs without running the extra session process, then use libpackagekit.
If you don't care, and just want things to work then
use the session interface.
If you are using GNOME, or running the
gpk-update-icon
then you can use the session dbus interface
provided by this process.
If you are not using GNOME, or choose to not use the gpk-update-icon
applet then you can use an alternate interface provided by your desktop.
Using this shared session service you can use the following DBUS methods to make PackageKit just do the right thing. All the additional confirmation, package downloads, GPG and EULA prompting is done automatically.
The DBUS methods are designed to be run syncronously, but can be run
async using dbus_g_proxy_begin_call
and then returning on
the DBusGProxyCallNotify
.
For example, the following code snippet would install a package by name:
#include <dbus/dbus-glib.h> DBusGConnection *connection; DBusGProxy *proxy; GError *error = NULL; gboolean ret; connection = dbus_g_bus_get (DBUS_BUS_SESSION, NULL); proxy = dbus_g_proxy_new_for_name (connection, "org.freedesktop.PackageKit", "/org/freedesktop/PackageKit", "org.freedesktop.PackageKit"); /* execute sync method */ ret = dbus_g_proxy_call (proxy, "InstallPackageName", &error, G_TYPE_STRING, "openoffice-clipart", G_TYPE_INVALID, G_TYPE_INVALID); if (!ret) { g_warning ("failed: %s", error->message); g_error_free (error); }
or in python...
import dbus try: bus = dbus.SessionBus() except dbus.DBusException, e: print 'Unable to connect to dbus: %s' % str(e) sys.exit() try: proxy = bus.get_object('org.freedesktop.PackageKit', '/org/freedesktop/PackageKit') iface = dbus.Interface(proxy, 'org.freedesktop.PackageKit') iface.InstallPackageName('openoffice-clipart') except dbus.DBusException, e: print 'Unable to use PackageKit: %s' % str(e)
The methods available on this interface are:
InstallPackageName("openoffice-clipart")
InstallProvideFile("/usr/share/fonts/sarai/Sarai_07.ttf")
InstallLocalFile("/home/dave/Desktop/lirc-0.6.6-4.rhfc1.dag.i686.rpm")
InstallMimeType("application/x-rpm")
Please email me or the mailing list if you have any other questions
![]() | Bugfix update |
![]() | Enhancement update |
![]() | High priority update |
![]() | Low priority update |
![]() | Normal update |
![]() | Security update |
NOTE:Not all the icons may show for some backends.
If you are using Fedora rawhide then only the bugfix icon will be show due to missing metadata. In the released versions of Fedora metadata is added to updates and the type of update can be found.
The Rawhide repository does not supply metadata needed for the update-viewer to display extra information about the update, such as changelogs, CVE and bugzilla references. Only released versions of Fedora have this metadata.
The process packagekitd
is not recognized by SELinux in Fedora 8.
Until the policy is fixed to handle system activation, you'll have
to run in permissive mode, rather than enforcing.
Using Fedora 9 or Rawhide, selinux-policy-3.0.8-62.fc8
will make the
yum
backend work correctly when enforcing.
The future backend yum2
will need further changes.
See Red Hat Bugzilla
for further information.
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.
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.
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.
Backends don't have to support all options of all methods. Just set an error and return false if not implemented.
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.
Upgrading, installing or removing packages has to be 100% silent.
The user cannot be prompted mid-transaction for questions as these will not be handled in PackageKit. The backend should do the right thing, as these questions mean very little to the average user.
The reasons for this are as follows:
EULAs or other agreements will have to be agreed to before the
transaction is processed using the EulaRequired
signal.
EULAs should preferably be shown per-user - i.e. the first time an application is run.
PackageKit will not install packages with broken maintainer scripts that
require a stdin.
Debian
policy clearly says that prompting on stdin
instead of using debconf is deprecated.
If this is attempted the backend should detect this and error out of the
transaction with PK_ERROR_ENUM_BROKEN_PACKAGE
.
We cannot and will not ask the user for random standard input.
See the Debian PackageKit wiki for more details and further discussion.
If the transaction needs to tell the user something, the Message()
method can be used that will localise the message up the stack, and also give the user a way
of ignoring duplicate messages of this type.
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.
PackageKit is not yet another system daemon. It quits when not doing anything, and only starts when something wants information or a task completed.
PackageKit does not do dependency resolution. This problem has already been solved by the backend systems and we don't really want to re-invent the wheel.
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.
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.
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.
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.
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 yum
, yum-updatesd
,
pup
and pirut
.
A joke that started on IRC late one night in '07. Put formally it is: Authentication or license prompts can only be done before the transaction has started, and messages or notices about the transaction can only be shown after the transaction has completed.
See the GNOME Translation Team web pages for how to contribute to GNOME localisation.
PackageKit is not sponsored by anyone. Whilst interning at Red Hat in '07 I spent a few days on the API and some UI designs, but all the coding is done in my free time. I now work at Red Hat full time.
Back to the main page