2007-08-20 05:48:13 -07:00
|
|
|
Hacking PackageKit
|
2007-07-31 09:53:31 -07:00
|
|
|
|
|
|
|
Coding Style
|
|
|
|
------------
|
|
|
|
Please stick to the existing coding style.
|
2007-10-16 10:58:32 -07:00
|
|
|
Tabs should be hard (not expanded to spaces), and set equivalent to
|
|
|
|
8 spaces.
|
|
|
|
|
2007-12-03 13:49:42 -08:00
|
|
|
All documentation and code should be in US English.
|
|
|
|
|
2007-10-16 10:58:32 -07:00
|
|
|
Please consider enabling git's default pre-commit hook:
|
|
|
|
|
|
|
|
$> cd PackageKit
|
|
|
|
$> chmod +x .git/hooks/pre-commit
|
|
|
|
|
|
|
|
This hook will run before every checkin, and check your changes for
|
|
|
|
suspicious use of whitespace.
|
2007-10-16 06:26:33 -07:00
|
|
|
|
2007-10-16 11:11:07 -07:00
|
|
|
In the C files use the following convention.
|
|
|
|
The number of spaces and tabs are very important!
|
|
|
|
|
|
|
|
/* map the roles to policykit rules */
|
2008-03-18 16:48:15 -07:00
|
|
|
if (role == PK_ROLE_ENUM_UPDATE_PACKAGES ||
|
2007-10-16 11:11:07 -07:00
|
|
|
role == PK_ROLE_ENUM_UPDATE_SYSTEM) {
|
|
|
|
policy = "org.freedesktop.packagekit.update";
|
|
|
|
} else if (role == PK_ROLE_ENUM_REMOVE_PACKAGE) {
|
|
|
|
policy = "org.freedesktop.packagekit.remove";
|
|
|
|
}
|
|
|
|
|
2008-03-18 16:48:15 -07:00
|
|
|
and please DO NOT use "!" for a null pointer check.
|
2007-10-16 11:11:07 -07:00
|
|
|
|
|
|
|
Functions are nearly always the same format, gtk-doc is optional:
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pk_engine_search_name:
|
|
|
|
**/
|
|
|
|
gboolean
|
|
|
|
pk_engine_search_name (PkEngine *engine, const gchar *search, GError **error)
|
|
|
|
{
|
|
|
|
gboolean ret;
|
|
|
|
PkTransactionItem *item;
|
|
|
|
|
|
|
|
g_return_val_if_fail (engine != NULL, FALSE);
|
|
|
|
g_return_val_if_fail (PK_IS_ENGINE (engine), FALSE);
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
Finally: DO NOT COMMIT TRAILING WHITESPACE.
|
|
|
|
|
|
|
|
Security
|
|
|
|
--------
|
|
|
|
Remember:
|
|
|
|
* The daemon is running as the root user
|
|
|
|
- no FIXME or TODO code please
|
|
|
|
* If the daemon crashes, then that's a DOS
|
|
|
|
* Text from the user (over the dbus interface) is insecure!
|
|
|
|
- even filters and enumerated values can be wrong
|
|
|
|
- users can use dbus-send to do bad stuff as users
|
|
|
|
* Never allocate a buffer on user input
|
|
|
|
* Output from backends is trusted, they are run from standard locations
|
|
|
|
|
2007-10-16 06:26:33 -07:00
|
|
|
Submitting Patches
|
|
|
|
------------------
|
2023-05-14 07:29:41 -07:00
|
|
|
We prefer patches submitted as pull requests to our GitHub project at
|
|
|
|
https://github.com/PackageKit/PackageKit
|
2007-10-16 06:26:33 -07:00
|
|
|
|
2023-05-14 07:29:41 -07:00
|
|
|
However, if you are unable to use GitHub, you can also submit patches
|
|
|
|
via email.
|
|
|
|
|
|
|
|
To do so, Use 'git format-patch' to generate patches against a checked
|
|
|
|
out copy of the source.
|
|
|
|
|
|
|
|
For example:
|
2007-10-16 06:26:33 -07:00
|
|
|
|
|
|
|
$> cd PackageKit
|
|
|
|
HACK HACK HACK
|
|
|
|
$> git commit -m "My first commit"
|
|
|
|
HACK HACK HACK
|
|
|
|
$> git commit -m "My second commit"
|
|
|
|
$> git format-patch -M HEAD^^
|
|
|
|
0001-My-first-commit.patch
|
|
|
|
0002-My-second-commit.patch
|
|
|
|
|
|
|
|
Send these patches in an introductory email as attachments to
|
2010-01-29 03:52:47 -08:00
|
|
|
packagekit@lists.freedesktop.org
|
2007-10-16 11:11:07 -07:00
|
|
|
|
2023-05-14 07:29:41 -07:00
|
|
|
Commit/Patch Style
|
|
|
|
------------------
|
|
|
|
Commits (and thus patches) should be structured such that each one
|
|
|
|
is a logically distinct change that stands well and can be tested
|
|
|
|
on its own.
|
|
|
|
|
|
|
|
Commit/Patch messages should be wrapped at 72 characters, and the
|
|
|
|
subject line (minus the subsystem prefix) should be less than 50
|
|
|
|
characters.
|
|
|
|
|
|
|
|
What we mean by subsystem prefix is the portion of the codebase
|
|
|
|
that is being modified.
|
|
|
|
|
|
|
|
For example, if you are changing something in the main library,
|
|
|
|
use "lib:" as the prefix of the patch subject. If you are
|
|
|
|
changing something in one of the backends, use the backend name
|
|
|
|
as the prefix in the patch subject.
|
|
|
|
|
|
|
|
There are a number of examples of this already in the revision
|
|
|
|
history, so look at any number of them for good examples.
|
|
|
|
|
|
|
|
Finally, please do not use commit messages as a means for
|
|
|
|
advertising. The revision history is not a place for rent-free
|
|
|
|
permanent advertising. It can be especially problematic as
|
|
|
|
sponsoring entities change, rename, or such. That means that
|
|
|
|
tags like "Sponsored-by" or similar are not allowed.
|