Scroll to navigation

CLICK(1) Click Packages CLICK(1)

NAME

click - package management tool for Ubuntu Touch

SYNOPSIS

click command [options] [arguments]

DESCRIPTION

Click is a packaging format for Ubuntu Touch applications, independent of the packaging format used to deliver the underlying system. The click program is the basic tool used to build, install, remove, and otherwise manipulate these packages.

click’s various functions are available via a number of commands, described in detail below.

While click supports per-user installation, packages are normally unpacked as a special clickpkg user, to ensure that applications cannot modify their own code; it is a design goal to ensure that click can be used to install untrusted code which is then confined using AppArmor. As such, click should normally be run as root (e.g. using sudo) when installing packages; it will drop privileges as needed.

COMMANDOVERVIEW

click build DIRECTORY
click buildsource DIRECTORY
click chroot
click contents PATH
click framework list
click hook install HOOK
click hook remove HOOK
click hook run-system
click hook run-user
click info PATH
click install PACKAGE-FILE
click list
click pkgdir {PACKAGE-NAME|PATH}
click register PACKAGE-NAME VERSION
click unregister PACKAGE-NAME [VERSION]
click verify PACKAGE-FILE


COMMANDS

clickbuildDIRECTORY

Build a Click package from the contents of DIRECTORY. The build directorymust contain a JSON-formatted manifest, described further in Click’sfile-format documentation; by default, this is expected to be inmanifest.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 unpackingand repacking an existing package, this is not normally recommended becauseit requires some care to put the manifest file back in the right place. Itis best to keep your application’s code in separate revision control ratherthan relying on recovering it from packages.

Options:

Read package manifest from PATH(default: manifest.json).
Ignore the given shell-patternwhen building the package.The option may be repeated multipletimes to list multiple patterns toexclude.
Don’t run checks from click-reviewers-tools onthe 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:

Read package manifest from PATH(default: manifest.json).
Ignore the given shell-patternwhen building the package.The option may be repeated multipletimes to list multiple patterns toexclude.

clickchroot

Manage chroot environments for cross-building Click packages.

Options:

Set the target architecture.
Set the target framework (default:ubuntu-sdk-13.10).
Set the target series fornewly-created chroots (default: aseries appropriate for theframework).This option is mainly for debugging;use -f instead.

Subcommands:

Begin a persistent chroot session.
Create a chroot.
Destroy a chroot.
End a persistent chroot session.
Install packages in the chroot.
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 click chroot maint exits.

If a session name is given, run the command in that session. Thesession must previously have been created by click chroot begin-session.

Run a program in the chroot.

If a session name is given, run the command in that session. Thesession must previously have been created by click chroot begin-session.

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, byway of dh_click(1).

Options:

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, byway of dh_click(1).

Options:

Look for additional packages in PATH.

clickhookrun-system

Run all system-level hooks for all installed Click packages. This is usefulwhen starting up from images with preinstalled packages which may not havehad their system-level hooks run properly when building the image.

Options:

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 havebeen preinstalled and registered for all users.

Options:

Look for additional packages in PATH.
Run user-level hooks for USER (default: currentuser).

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:

Look for additional packages in PATH.
List packages registered by USER (if you havepermission).

clickinstallPACKAGE-FILE

Install the Click package in PACKAGE-FILE.

This is a low-level tool; to install a package as an ordinary user youshould generally use pkcon install-local PACKAGE-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.)

click install 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 orfor all users; if you do not do this then the packages may begarbage-collected later. You can do this using the --user or --all-users options to this command, or using the click register command.

Options:

Install packages underneath PATH.
Install despite missing system framework.
Register package for USER.
--all-users
Register package for all users.

clicklist

Display a list of installed packages, either as one package per line witheach line containing a package name and version separated by a tab (thedefault), or as a JSON array of manifests.

By default, click list shows only packages registered for the current user. The --all option causes it to show all installed packages, regardless of user registrations.

Options:

Look for additional packages in PATH.
List all installed packages.
List packages registered by USER (if you havepermission).
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 wasfound.

Options:

Look for additional packages in PATH.
List packages registered by USER (if you havepermission).

clickregisterPACKAGE-NAMEVERSION

Register an installed Click package for a user. This will normally causeuser-level hooks to be run for that user, which are needed for things suchas making the application’s .desktop file available to the user interface.

Options:

Look for additional packages in PATH.
Register package for USER (default: currentuser).
--all-users
Register package for all users.

clickunregisterPACKAGE-NAME[VERSION]

Unregister an installed Click package for a user, and remove it entirely ifno other users still have it registered and if it does not appear to berunning. 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 inorder to be removed.

Options:

Look for additional packages in PATH.
Unregister package for USER (default:$SUDO_USER, if known).
--all-users
Unregister package that was previouslyregistered 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:

Install packages underneath PATH.
Install despite missing system framework.

AUTHOR

Colin Watson

COPYRIGHT

2022, Canonical Ltd.

2022-02-02 0.5