// Copyright (C) 2021 The Qt Company Ltd.
// Copyright (C) 2019 Luxoft Sweden AB
// Copyright (C) 2018 Pelagicore AG
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only

/*!

\page installer.html
\ingroup qtappman
\ingroup qtappman-highlights
\title Package Installation
\brief Discusses the package installation infrastructure.
\keyword Installer

\section1 Dynamically Installing, Updating, and Removing Packages

After applications have been packaged by the \l {Packager}{\c appman-packager} tool, they can be
installed by the application manager at runtime. There are two interfaces for this functionality:

\list
    \li A QML interface for use within the application manager process.
    \li A D-Bus interface for use by any process that is allowed to talk to the application
        manager's \c PackageManager interface.
\endlist

Both interfaces are very similar and are described in the PackageManager.

\note A prerequisite for dynamically installed application packages is a valid
\l {Configuration}{\c installationDir configuration} for the application manager.

\section1 Packages

The application manager has its own \l {Package Format}. It comes with the \l {Packager}{\c
appman-packager} command-line tool, for you to create and verify those packages.

\section1 Installation Sources

When triggering a package installation, you have to provide a URL to the application manager as
the source of the package. Out of the box, the application manager accepts the following schemes:

\table
\header
  \li Scheme
  \li Description
\row
  \li \c file://
  \li A local filesystem path.
\row
  \li \c http://, \c https:// and \c ftp://
  \li A remote path that is downloaded via QNetworkAccessManager.
\row
  \li \c socket://
  \li A path to a UNIX-domain socket in the local filesystem. This is very useful for streaming in
      packages, if you do not want to (or can) use the built-in downloader, or if your packages are
      wrapped inside another customer-specific distribution file format.
\endtable

All of the above methods work asynchronously and also support streaming: this means that the actual
installation is done while the package is being downloaded. If the package is successfully verified
after the download, it only needs a quick finalization step. Otherwise, if an error occurred, the
installation process is simply canceled and rolled back.

\section1 Public Key Infrastructure

To use signed packages, you require a Public Key Infrastructure (PKI) to support this, which means
that you need two Certificate Authorities (CAs):

\list
  \li A \e {Developer CA}: responsible for creating certificates that are distributed to developers
      in P12 format. The developers use these certificates to developer-sign their packages, using
      the \l {Packager}, before submitting to an app store.
  \li An \e {App-Store CA}: responsible for creating certificates for use by app store server
      back ends to store-sign packages, before they are downloaded and installed onto devices.
\endlist

Both these CAs can be the same or they can be derived from a common root CA.

For the device, you need to install one or both of these CA certificates, including any root or
intermediary ones. But, this depends on the type of package you want the user to be able to
install. Which CA certificates to load is specified via \l {ca certificates} {the config file}.

The application manager sources have a script,
\c tests/data/certificates/create-test-certificates.sh, that sets up such a PKI for the internal
unit tests. This script is \b not for use in production, but only for use in developing with
signed packages.

\section1 Related Content

\list
  \li \l {Package Format}
  \li \l {Packager}
  \li \l {PackageManager}{PackageManager API}
\endlist
*/