clickbuildDIRECTORY
Build a Click package from the contents of DIRECTORY. The build directory must contain a JSON-formatted
manifest, described further in Click’s file-format documentation; by default, this is expected to be in
manifest.json at the top level of the build directory.
The resulting .click file is written to the current directory, so to avoid confusion you should generally
ensure that your working directory is not inside the build directory when running this command.
While it is possible to build a new version of a Click package by unpacking and repacking an existing
package, this is not normally recommended because it requires some care to put the manifest file back in
the right place. It is best to keep your application’s code in separate revision control rather than
relying on recovering it from packages.
Options:
-mPATH, --manifest=PATH
Read package manifest from PATH (default: manifest.json).
-Ifile-pattern, --ignore=file-pattern
Ignore the given shell-pattern when building the package. The option may be repeated multiple
times to list multiple patterns to exclude.
--no-validate
Don’t run checks from click-reviewers-tools on the resulting .click file.
clickbuildsourceDIRECTORY
Build a source package in .tar.gz format from the contents of DIRECTORY. This allows you to distribute
source code in the case where your package contains compiled code (and so the Click package does not
constitute its own source).
The resulting .tar.gz file is written to the current directory, so to avoid confusion you should
generally ensure that your working directory is not inside the build directory when running this command.
Options:
-mPATH, --manifest=PATH
Read package manifest from PATH (default: manifest.json).
-Ifile-pattern, --ignore=file-pattern
Ignore the given shell-pattern when building the package. The option may be repeated multiple
times to list multiple patterns to exclude.
clickchroot
Manage chroot environments for cross-building Click packages.
Options:
-aARCH, --architectureARCH
Set the target architecture.
-fFRAMEWORK, --frameworkFRAMEWORK
Set the target framework (default: ubuntu-sdk-13.10).
-sSERIES, --seriesSERIES
Set the target series for newly-created chroots (default: a series appropriate for the framework).
This option is mainly for debugging; use -f instead.
Subcommands:
begin-sessionSESSION
Begin a persistent chroot session.
create Create a chroot.
destroy
Destroy a chroot.
end-sessionSESSION
End a persistent chroot session.
install[-nSESSION]PACKAGES
Install packages in the chroot.
maint[-nSESSION]COMMANDARGUMENTS
Run a maintenance command in the chroot. Unlike run, this runs its command as root inside the
chroot, and its effects on the chroot will persist after clickchrootmaint exits.
If a session name is given, run the command in that session. The session must previously have
been created by clickchrootbegin-session.
run[-nSESSION]COMMANDARGUMENTS
Run a program in the chroot.
If a session name is given, run the command in that session. The session must previously have
been created by clickchrootbegin-session.
upgrade[-nSESSION]
Upgrade the chroot.
clickcontentsPATH
Display the contents of the Click package in PATH as a file listing.
clickframeworklist
Display a list of available frameworks as one framework per line.
clickhookinstallHOOK
Install files associated with HOOK for any Click packages that attach to it.
This is normally only called by maintainer scripts of system packages, by way of dh_click(1).
Options:
--root=PATH
Look for additional packages in PATH.
clickhookremoveHOOK
Remove files associated with HOOK for any Click packages that attach to it.
This is normally only called by maintainer scripts of system packages, by way of dh_click(1).
Options:
--root=PATH
Look for additional packages in PATH.
clickhookrun-system
Run all system-level hooks for all installed Click packages. This is useful when starting up from images
with preinstalled packages which may not have had their system-level hooks run properly when building the
image.
Options:
--root=PATH
Look for additional packages in PATH.
clickhookrun-user
Run all user-level hooks for all Click packages registered for a given user. This is useful at session
startup to catch up with packages that may have been preinstalled and registered for all users.
Options:
--root=PATH
Look for additional packages in PATH.
--user=USER
Run user-level hooks for USER (default: current user).
clickinfo{PACKAGE-NAME|PACKAGE-FILE}
When given a package name (that is, a string containing no / characters), display the manifest for that
package, if it is registered for the current user.
When given a path (that is, a string containing at least one / character, or a string containing no /
characters that is not a registered package name), attempt to treat that as a path to a file containing a
Click package and display the manifest for that package.
Options:
--root=PATH
Look for additional packages in PATH.
--user=USER
List packages registered by USER (if you have permission).
clickinstallPACKAGE-FILE
Install the Click package in PACKAGE-FILE.
This is a low-level tool; to install a package as an ordinary user you should generally use pkconinstall-localPACKAGE-FILE or some higher-level user interface instead, which take care to use the
correct set of options. (Do not use sudo when invoking pkcon, as it needs to know the calling user.)
clickinstall may be used to preinstall a package in an image such that it will be available to all users
by default. When doing this, you should normally install it to one of the databases defined in
/etc/click/databases/ other than the default of /var/lib/clickpkg. For example:
sudo click install –root=/custom/click –all-users foo.click
The --force-missing-framework option is necessary while working with development versions of SDKs which
have not yet put a framework declaration in place.
You should always register installed packages either for a specific user or for all users; if you do not
do this then the packages may be garbage-collected later. You can do this using the --user or
--all-users options to this command, or using the clickregister command.
Options:
--root=PATH
Install packages underneath PATH.
--force-missing-framework
Install despite missing system framework.
--user=USER
Register package for USER.
--all-users
Register package for all users.
clicklist
Display a list of installed packages, either as one package per line with each line containing a package
name and version separated by a tab (the default), or as a JSON array of manifests.
By default, clicklist shows only packages registered for the current user. The --all option causes it
to show all installed packages, regardless of user registrations.
Options:
--root=PATH
Look for additional packages in PATH.
--all List all installed packages.
--user=USER
List packages registered by USER (if you have permission).
--manifest
Format output as a JSON array of manifests.
clickpkgdir{PACKAGE-NAME|PATH}
When given a package name (that is, a string containing no / characters), display the directory where
that package is installed, if it is registered for the current user.
When given a path (that is, a string containing at least one / character), attempt to treat that as a
path to a file within a Click package and print the top-level directory where that package is installed,
if one exists. This is particularly useful in hooks that need to find the top-level package directory
based on a symbolic link to a single file within it.
Exits zero if and only if a directory for the given package name or path was found.
Options:
--root=PATH
Look for additional packages in PATH.
--user=USER
List packages registered by USER (if you have permission).
clickregisterPACKAGE-NAMEVERSION
Register an installed Click package for a user. This will normally cause user-level hooks to be run for
that user, which are needed for things such as making the application’s .desktop file available to the
user interface.
Options:
--root=PATH
Look for additional packages in PATH.
--user=USER
Register package for USER (default: current user).
--all-users
Register package for all users.
clickunregisterPACKAGE-NAME[VERSION]
Unregister an installed Click package for a user, and remove it entirely if no other users still have it
registered and if it does not appear to be running. This will normally cause user-level hooks to be run
for that user, which are needed for things such as removing the application’s .desktop file from the user
interface.
If a version is specified, then the registered version must match it in order to be removed.
Options:
--root=PATH
Look for additional packages in PATH.
--user=USER
Unregister package for USER (default: $SUDO_USER, if known).
--all-users
Unregister package that was previously registered for all users.
clickverifyPACKAGE-FILE
Verify the Click package in PACKAGE-FILE.
The --force-missing-framework option is necessary while working with development versions of SDKs which
have not yet put a framework declaration in place.
Options:
--root=PATH
Install packages underneath PATH.
--force-missing-framework
Install despite missing system framework.
Install Now
Emojis
PNG Icons
