CLICK(1)

📦
version 0.5.2 · 6 versions
, in debian trixie, ubuntu questing

✨ CLICK(1) ✨

okay bestie, buckle up, we're doing the click manual page 💖 this is Click Packages, section 1 of the manual, and it's literally the package management tool for Ubuntu Touch, no cap 🫶

🌸 NAME 🌸

click — package management tool for Ubuntu Touch 👑

🎀 SYNOPSIS 🎀

click command [options] [arguments]

like, that's the whole vibe. you give it a command, you give it some options, you give it some arguments, and it does the thing ✨

💅 DESCRIPTION 💅

okay so. Click is a packaging format for Ubuntu Touch applications, and the important part is that it's independent of the packaging format used to deliver the underlying system. so the system underneath can be doing whatever it wants and click is just over here doing its own thing, iconic, we love a self-sufficient queen 💜

and then the click program itself? it's the basic tool you use to build, install, remove, and otherwise manipulate these packages. all of the above. it's giving multitasking main character energy 💅

click's various functions are available via a number of commands, and bestie, they are described in detail below. we're getting to all of them, don't worry, I would never gatekeep 🙈

now here's the part where you actually have to pay attention, fr fr. While click supports per-user installation, packages are normally unpacked as a special clickpkg user, to ensure that applications cannot modify their own code. and honestly? that's the whole point. it is a design goal to ensure that click can be used to install untrusted code which is then confined using AppArmor 🛡️ so like, the sketchy app is in the group chat but it's on mute, yk?

As such, click should normally be run as root (e.g. using sudo) when installing packages — and it will drop privileges as needed. it knows when to step back and let someone else have the aux, we stan a considerate icon 🫶

🌈 COMMAND OVERVIEW 🌈

here's the whole lineup, the full roster, the main characters ⭐:

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

that's the vibe check passed ✅ every single one of these gets its own moment in the spotlight, so like… keep reading, bestie, we're not done 😌

🛠️ COMMANDS 🛠️

Ok bestie, this is the big one. Every command, every flag, no skipping. Grab a snack. 💖

📦 click build DIRECTORY

Build a Click package out of whatever's chillin' in DIRECTORY. The build directory has to contain a JSON-formatted manifest — Click's file-format documentation explains it properly, but by default it lives at manifest.json right at the top level of the build directory.

The resulting .click file gets written to the current directory, so to avoid a whole confused situation you should generally make sure your working directory is not inside the build directory when you run this. For real, it's giving chaos otherwise.

So like, yes, technically you can build a new version of a Click package by unpacking and repacking an existing one — but this is not normally recommended, because it takes actual care to put the manifest file back in the right place. Best practice: keep your application's code in separate revision control rather than relying on recovering it from packages. Don't do crimes against your own repo. 🙈

Options:

  • -m PATH, --manifest=PATH — Read package manifest from PATH (default: manifest.json).
  • -I file-pattern, --ignore=file-pattern — Ignore the given shell-pattern when building the package. You can repeat this option as many times as you want to list multiple patterns to exclude. Go off. ✨
  • --no-validate — Don't run checks from click-reviewers-tools on the resulting .click file.

🧁 click buildsource DIRECTORY

Build a source package in .tar.gz format from the contents of DIRECTORY. This is the move when you wanna distribute source code in the case where your package contains compiled code (and so the Click package doesn't constitute its own source). Like, the binary isn't the source, bestie. 🦋

The resulting .tar.gz file is written to the current directory, so — same energy as build — you should generally ensure that your working directory is not inside the build directory when running this command.

Options:

  • -m PATH, --manifest=PATH — Read package manifest from PATH (default: manifest.json).
  • -I file-pattern, --ignore=file-pattern — Ignore the given shell-pattern when building the package. Repeatable, multiple times, multiple patterns to exclude. Periodt.

🏰 click chroot

Manage chroot environments for cross-building Click packages. Main character infrastructure behavior, honestly.

Options:

  • -a ARCH, --architecture ARCH — Set the target architecture.
  • -f FRAMEWORK, --framework FRAMEWORK — Set the target framework (default: ubuntu-sdk-13.10).
  • -s SERIES, --series SERIES — 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-session SESSION — Begin a persistent chroot session.
  • create — Create a chroot.
  • destroy — Destroy a chroot.
  • end-session SESSION — End a persistent chroot session.
  • install [-n SESSION] PACKAGES — Install packages in the chroot.
  • maint [-n SESSION] COMMAND ARGUMENTS — 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. The session must previously have been created by click chroot begin-session.

  • run [-n SESSION] COMMAND ARGUMENTS — 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 click chroot begin-session.

  • upgrade [-n SESSION] — Upgrade the chroot.

🔍 click contents PATH

Display the contents of the Click package in PATH as a file listing. Peek inside. No cap. 💅

🌈 click framework list

Display a list of available frameworks as one framework per line. Clean, simple, iconic.

🪝 click hook install HOOK

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). So like, iykyk — you probably shouldn't be typing this by hand.

Options:

  • --root=PATH — Look for additional packages in PATH.

🪝 click hook remove HOOK

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.

🪝 click hook run-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. Catching up on the drama that happened while nobody was looking. 😭

Options:

  • --root=PATH — Look for additional packages in PATH.

🪝 click hook run-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).

🫧 click info {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).

💖 click install PACKAGE-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 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.) Not me watching you sudo the wrong thing — don't. 🙈

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 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 click register command.

⚠️ Register your packages, bestie. Unregistered packages can get garbage-collected and just vanish. It's giving gone girl. 💀

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.

📋 click list

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, 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:

  • --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.

📂 click pkgdir {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. Lowkey genius. 🧚

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).

✍️ click register PACKAGE-NAME VERSION

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. Slay, your app shows up now. ✨

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.

🚪 click unregister PACKAGE-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. No partial matches, no guessing. 💅

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.

✅ click verify PACKAGE-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.

👑 AUTHOR 👑

Colin Watson

2013, Canonical Ltd.

And that's the whole page, bestie — you made it to the end and you ate. 💖✨ The source here is version 0.5, dated 2025-05-05, and the page goes by CLICK(1). Go build something iconic. 🎀🦋🌈

📦 where this page comes from