Provided by: aptly_1.5.0+ds1-2ubuntu0.1_amd64 
NAME
aptly - Debian repository management tool
SYNOPSIS
Common command format:
aptly [global options...] command subcommand [options...] arguments
aptly has integrated help that matches contents of this manual page, to get help, prepend
help to command name:
aptly help mirror create
DESCRIPTION
aptly is a tool to create partial and full mirrors of remote repositories, manage local
repositories, filter them, merge, upgrade individual packages, take snapshots and publish
them back as Debian repositories.
aptly’s goal is to establish repeatability and controlled changes in a package-centric
environment. aptly allows one to fix a set of packages in a repository, so that package
installation and upgrade becomes deterministic. At the same time aptly allows one to
perform controlled, fine-grained changes in repository contents to transition your package
environment to new version.
CONFIGURATION
aptly looks for configuration file first in ~/.aptly.conf then in /etc/aptly.conf and, if
no config file found, new one is created in home directory. If -config= flag is specified,
aptly would use config file at specified location. Also aptly needs root directory for
database, package and published repository storage. If not specified, directory defaults
to ~/.aptly, it will be created if missing.
Configuration file is stored in JSON format (default values shown below):
{
"rootDir": "$HOME/.aptly",
"downloadConcurrency": 4,
"downloadSpeedLimit": 0,
"downloadRetries": 0,
"downloader": "default",
"databaseOpenAttempts": 10,
"architectures": [],
"dependencyFollowSuggests": false,
"dependencyFollowRecommends": false,
"dependencyFollowAllVariants": false,
"dependencyFollowSource": false,
"dependencyVerboseResolve": false,
"gpgDisableSign": false,
"gpgDisableVerify": false,
"gpgProvider": "gpg",
"downloadSourcePackages": false,
"skipLegacyPool": true,
"ppaDistributorID": "ubuntu",
"ppaCodename": "",
"skipContentsPublishing": false,
"FileSystemPublishEndpoints": {
"test1": {
"rootDir": "/opt/srv1/aptly_public",
"linkMethod": "symlink"
},
"test2": {
"rootDir": "/opt/srv2/aptly_public",
"linkMethod": "copy",
"verifyMethod": "md5"
},
"test3": {
"rootDir": "/opt/srv3/aptly_public",
"linkMethod": "hardlink"
}
},
"S3PublishEndpoints": {
"test": {
"region": "us-east-1",
"bucket": "repo",
"endpoint": "",
"awsAccessKeyID": "",
"awsSecretAccessKey": "",
"prefix": "",
"acl": "public-read",
"storageClass": "",
"encryptionMethod": "",
"plusWorkaround": false,
"disableMultiDel": false,
"forceSigV2": false,
"debug": false
}
},
"SwiftPublishEndpoints": {
"test": {
"container": "repo",
"osname": "",
"password": "",
"prefix": "",
"authurl": "",
"tenant": "",
"tenantid": ""
}
},
"AzurePublishEndpoints": {
"test": {
"accountName": "",
"accountKey": "",
"container": "repo",
"prefix": ""
"endpoint": "blob.core.windows.net"
}
}
}
Options:
rootDir
is root of directory storage to store database (rootDir/db), downloaded packages
(rootDir/pool) and the default for published repositories (rootDir/public)
downloadConcurrency
is a number of parallel download threads to use when downloading packages
downloadSpeedLimit
limit in kbytes/sec on download speed while mirroring remote repositories
downloadRetries
number of retries for download attempts
databaseOpenAttempts
number of attempts to open DB if it’s locked by other instance; could be overridden
with option -db-open-attempts
architectures
is a list of architectures to process; if left empty defaults to all available
architectures; could be overridden with option -architectures
dependencyFollowSuggests
follow contents of Suggests: field when processing dependencies for the package
dependencyFollowRecommends
follow contents of Recommends: field when processing dependencies for the package
dependencyFollowAllVariants
when dependency looks like package-a | package-b, follow both variants always
dependencyFollowSource
follow dependency from binary package to source package
dependencyVerboseResolve
print additional details while resolving dependencies (useful for debugging)
gpgDisableSign
don’t sign published repositories with gpg(1), also can be disabled on per-repo
basis using -skip-signing flag when publishing
gpgDisableVerify
don’t verify remote mirrors with gpg(1), also can be disabled on per-mirror basis
using -ignore-signatures flag when creating and updating mirrors
gpgProvider
implementation of PGP signing/validation - gpg for external gpg utility or internal
to use Go internal implementation; gpg1 might be used to force use of GnuPG 1.x,
gpg2 enables GnuPG 2.x only; default is to use GnuPG 1.x if available and GnuPG 2.x
otherwise
downloadSourcePackages
if enabled, all mirrors created would have flag set to download source packages;
this setting could be controlled on per-mirror basis with -with-sources flag
skipLegacyPool
in aptly up to version 1.0.0, package files were stored in internal package pool
with MD5-dervied path, since 1.1.0 package pool layout was changed; if option is
enabled, aptly stops checking for legacy paths; by default option is enabled for
new aptly installations and disabled when upgrading from older versions
ppaDistributorID, ppaCodename
specifies paramaters for short PPA url expansion, if left blank they default to
output of lsb_release command
FileSystemPublishEndpoints
configuration of local filesystem publishing endpoints (see below)
S3PublishEndpoints
configuration of Amazon S3 publishing endpoints (see below)
SwiftPublishEndpoints
configuration of OpenStack Swift publishing endpoints (see below)
FILESYSTEM PUBLISHING ENDPOINTS
aptly defaults to publish to a single publish directory under rootDir/public. For a more
advanced publishing strategy, you can define one or more filesystem endpoints in the
FileSystemPublishEndpoints list of the aptly configuration file. Each endpoint has a name
and the following associated settings:
rootDir
The publish directory, e.g., /opt/srv/aptly_public.
linkMethod
This is one of hardlink, symlink or copy. It specifies how aptly links the files
from the internal pool to the published directory. If not specified, empty or
wrong, this defaults to hardlink.
verifyMethod
This is used only when setting the linkMethod to copy. Possible values are md5 and
size. It specifies how aptly compares existing links from the internal pool to the
published directory. The size method compares only the file sizes, whereas the md5
method calculates the md5 checksum of the found file and compares it to the desired
one. If not specified, empty or wrong, this defaults to md5.
In order to publish to such an endpoint, specify the endpoint as filesystem:endpoint-name
with endpoint-name as the name given in the aptly configuration file. For example:
aptly publish snapshot wheezy-main filesystem:test1:wheezy/daily
S3 PUBLISHING ENDPOINTS
aptly could be configured to publish repository directly to Amazon S3 (or S3-compatible
cloud storage). First, publishing endpoints should be described in aptly configuration
file. Each endpoint has name and associated settings:
region Amazon region for S3 bucket (e.g. us-east-1)
bucket bucket name
endpoint
(optional) when using S3-compatible cloud storage, specify hostname of service
endpoint here, region is ignored if endpoint is set (set region to some
human-readable name) (should be left blank for real Amazon S3)
prefix (optional) do publishing under specified prefix in the bucket, defaults to no
prefix (bucket root)
acl (optional) assign ACL to published files (one of the canned ACLs in Amazon
terminology). Useful values: private (default), public-read (public repository) or
none (don’t set ACL). Public repositories could be consumed by apt using HTTP
endpoint (Amazon bucket should be configured for "website hosting"), for private
repositories special apt S3 transport is required.
awsAccessKeyID, awsSecretAccessKey
(optional) Amazon credentials to access S3 bucket. If not supplied, environment
variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are used.
storageClass
(optional) Amazon S3 storage class, defaults to STANDARD. Other values available:
REDUCED_REDUNDANCY (lower price, lower redundancy)
encryptionMethod
(optional) server-side encryption method, defaults to none. Currently the only
available encryption method is AES256
plusWorkaround
(optional) workaround misbehavior in apt and Amazon S3 for files with + in filename
by creating two copies of package files with + in filename: one original and
another one with spaces instead of plus signs With plusWorkaround enabled, package
files with plus sign would be stored twice. aptly might not cleanup files with
spaces when published repository is dropped or updated (switched) to new version of
repository (snapshot)
disableMultiDel
(optional) for S3-compatible cloud storages which do not support MultiDel S3 API,
enable this setting (file deletion would be slower with this setting enabled)
forceSigV2
(optional) disable Signature V4 support, useful with non-AWS S3-compatible object
stores which do not support SigV4, shouldn’t be enabled for AWS
debug (optional) enables detailed request/response dump for each S3 operation
In order to publish to S3, specify endpoint as s3:endpoint-name: before publishing prefix
on the command line, e.g.:
aptly publish snapshot wheezy-main s3:test:
OPENSTACK SWIFT PUBLISHING ENDPOINTS
aptly could be configured to publish repository directly to OpenStack Swift. First,
publishing endpoints should be described in aptly configuration file. Each endpoint has
name and associated settings:
container
container name
prefix (optional) do publishing under specified prefix in the container, defaults to no
prefix (container root)
osname, password
(optional) OpenStack credentials to access Keystone. If not supplied, environment
variables OS_USERNAME and OS_PASSWORD are used.
tenant, tenantid
(optional) OpenStack tenant name and id (in order to use v2 authentication).
authurl
(optional) the full url of Keystone server (including port, and version). example
http://identity.example.com:5000/v2.0
In order to publish to Swift, specify endpoint as swift:endpoint-name: before publishing
prefix on the command line, e.g.:
aptly publish snapshot jessie-main swift:test:
PACKAGE QUERY
Some commands accept package queries to identify list of packages to process. Package
query syntax almost matches reprepro query language. Query consists of the following
simple terms:
direct package reference
reference to exaclty one package. Format is identical to the way aptly lists
packages in show commands with -with-packages flag: name_version_arch, e.g.:
libmysqlclient18_5.5.35-rel33.0-611.squeeze_amd64
dependency condition
syntax follows Debian dependency specification: package_name followed by optional
version specification and architecture limit, e.g: mysql-client (>= 3.6).
query against package fields
syntax is the same as for dependency conditions, but instead of package name field
name is used, e.g: Priority (optional).
Supported fields:
○ all field names from Debian package control files are supported except for Filename,
MD5sum, SHA1, SHA256, Size, Files, Checksums-SHA1, Checksums-SHA256.
○ $Source is a name of source package (for binary packages)
○ $SourceVersion is a version of source package
○ $Architecture is Architecture for binary packages and source for source packages, when
matching with equal (=) operator, package with any architecture matches all
architectures but source.
○ $Version has the same value as Version, but comparison operators use Debian version
precedence rules
○ $PackageType is deb for binary packages and source for source packages
Operators:
= strict match, default operator is no operator is given
>=, <=, =, >> (strictly greater), << (strictly less)
lexicographical comparison for all fields and special rules when comparing package
versions
% pattern matching, like shell patterns, supported special symbols are: [^]?*, e.g.:
$Version (% 3.5-*)
~ regular expression matching, e.g.: Name (~ .*-dev)
Simple terms could be combined into more complex queries using operators , (and), | (or)
and ! (not), parentheses () are used to change operator precedence. Match value could be
enclosed in single (’) or double (") quotes if required to resolve ambiguity, quotes
inside quoted string should escaped with slash (\).
Examples:
mysql-client
matches package mysql-client of any version and architecture (including source),
also matches packages that Provide: mysql-client.
mysql-client (>= 3.6)
matches package mysql-client with version greater or equal to 3.6. Valid operators
for version are: >=, <=, =, >> (strictly greater), << (strictly less).
mysql-client {i386}
matches package mysql-client on architecture i386, architecture all matches all
architectures but source.
mysql-client (>= 3.6) {i386}
version and architecture conditions combined.
libmysqlclient18_5.5.35-rel33.0-611.squeeze_amd64
direct package reference.
$Source (nginx)
all binary packages with nginx as source package.
!Name (~ .*-dev), mail-transport, $Version (>= 3.5)
matches all packages that provide mail-transport with name that has no suffix -dev
and with version greater or equal to 3.5.
When specified on command line, query may have to be quoted according to shell rules, so
that it stays single argument:
aptly repo import percona stable ’mysql-client (>= 3.6)’
PACKAGE DISPLAY FORMAT
Some aptly commands (aptly mirror search, aptly package search, ...) support -format flag
which allows to customize how search results are printed. Golang templates are used to
specify display format, with all package stanza fields available to template. In addition
to package stanza fields aptly provides:
Key internal aptly package ID, unique for all packages in aptly (combination of
ShortKey and FilesHash).
FilesHash
hash that includes MD5 of all packages files.
ShortKey
package ID, which is unique in single list (mirror, repo, snapshot, ...), but not
unique in whole aptly package collection.
For example, default aptly display format could be presented with the following template:
{{.Package}}_{{.Version}}_{{.Architecture}}. To display package name with dependencies:
{{.Package}} | {{.Depends}}. More information on Golang template syntax:
http://godoc.org/text/template
GLOBAL OPTIONS
-architectures=
list of architectures to consider during (comma-separated), default to all
available
-config=
location of configuration file (default locations are /etc/aptly.conf,
~/.aptly.conf)
-db-open-attempts=10
number of attempts to open DB if it’s locked by other instance
-dep-follow-all-variants
when processing dependencies, follow a & b if dependency is ’a|b’
-dep-follow-recommends
when processing dependencies, follow Recommends
-dep-follow-source
when processing dependencies, follow from binary to Source packages
-dep-follow-suggests
when processing dependencies, follow Suggests
-dep-verbose-resolve
when processing dependencies, print detailed logs
-gpg-provider=
PGP implementation ("gpg", "gpg1", "gpg2" for external gpg or "internal" for Go
internal implementation)
CREATE NEW MIRROR
aptly mirror create name archive url distribution [component1 ...]
Creates mirror name of remote repository, aptly supports both regular and flat Debian
repositories exported via HTTP and FTP. aptly would try download Release file from remote
repository and verify its’ signature. Command line format resembles apt utlitily
sources.list(5).
PPA urls could specified in short format:
$ aptly mirror create name ppa:user/project
Example:
$ aptly mirror create wheezy-main http://mirror.yandex.ru/debian/ wheezy main
Options:
-filter=
filter packages in mirror
-filter-with-deps
when filtering, include dependencies of matching packages as well
-force-architectures
(only with architecture list) skip check that requested architectures are listed in
Release file
-force-components
(only with component list) skip check that requested components are listed in
Release file
-ignore-signatures
disable verification of Release file signatures
-keyring=
gpg keyring to use when verifying Release file (could be specified multiple times)
-with-installer
download additional not packaged installer files
-with-sources
download source packages in addition to binary packages
-with-udebs
download .udeb packages (Debian installer support)
LIST MIRRORS
aptly mirror list
List shows full list of remote repository mirrors.
Example:
$ aptly mirror list
Options:
-json display list in JSON format
-raw display list in machine-readable format
SHOW DETAILS ABOUT MIRROR
aptly mirror show name
Shows detailed information about the mirror.
Example:
$ aptly mirror show wheezy-main
Options:
-json display record in JSON format
-with-packages
show detailed list of packages and versions stored in the mirror
DELETE MIRROR
aptly mirror drop name
Drop deletes information about remote repository mirror name. Package data is not deleted
(since it could still be used by other mirrors or snapshots). If mirror is used as source
to create a snapshot, aptly would refuse to delete such mirror, use flag -force to
override.
Example:
$ aptly mirror drop wheezy-main
Options:
-force force mirror deletion even if used by snapshots
UPDATE MIRROR
aptly mirror update name
Updates remote mirror (downloads package files and meta information). When mirror is
created, this command should be run for the first time to fetch mirror contents. This
command can be run multiple times to get updated repository contents. If interrupted,
command can be safely restarted.
Example:
$ aptly mirror update wheezy-main
Options:
-download-limit=0
limit download speed (kbytes/sec)
-downloader=default
downloader to use (e.g. grab)
-force force update mirror even if it is locked by another process
-ignore-checksums
ignore checksum mismatches while downloading package files and metadata
-ignore-signatures
disable verification of Release file signatures
-keyring=
gpg keyring to use when verifying Release file (could be specified multiple times)
-max-tries=1
max download tries till process fails with download error
-skip-existing-packages
do not check file existence for packages listed in the internal database of the
mirror
RENAMES MIRROR
aptly mirror rename old-name new-name
Command changes name of the mirror.Mirror name should be unique.
Example:
$ aptly mirror rename wheezy-min wheezy-main
EDIT MIRROR SETTINGS
aptly mirror edit name
Command edit allows one to change settings of mirror: filters, list of architectures.
Example:
$ aptly mirror edit -filter=nginx -filter-with-deps some-mirror
Options:
-archive-url=
archive url is the root of archive
-filter=
filter packages in mirror
-filter-with-deps
when filtering, include dependencies of matching packages as well
-ignore-signatures
disable verification of Release file signatures
-keyring=
gpg keyring to use when verifying Release file (could be specified multiple times)
-with-installer
download additional not packaged installer files
-with-sources
download source packages in addition to binary packages
-with-udebs
download .udeb packages (Debian installer support)
SEARCH MIRROR FOR PACKAGES MATCHING QUERY
aptly mirror search name [package-query]
Command search displays list of packages in mirror that match package query
If query is not specified, all the packages are displayed.
Example:
$ aptly mirror search wheezy-main ’$Architecture (i386), Name (% *-dev)’
Options:
-format=
custom format for result printing
-with-deps
include dependencies into search results
ADD PACKAGES TO LOCAL REPOSITORY
aptly repo add name
Command adds packages to local repository from .deb, .udeb (binary packages) and .dsc
(source packages) files. When importing from directory aptly would do recursive scan
looking for all files matching .[u]deb or.dsc patterns. Every file discovered would be
analyzed to extract metadata, package would then be created and added to the database.
Files would be imported to internal package pool. For source packages, all required files
are added automatically as well. Extra files for source package should be in the same
directory as *.dsc file.
Example:
$ aptly repo add testing myapp-0.1.2.deb incoming/
Options:
-force-replace
when adding package that conflicts with existing package, remove existing package
-remove-files
remove files that have been imported successfully into repository
COPY PACKAGES BETWEEN LOCAL REPOSITORIES
aptly repo copy src-name dst-name package-query ...
Command copy copies packages matching package-query from local repo src-name to local repo
dst-name.
Example:
$ aptly repo copy testing stable ’myapp (=0.1.12)’
Options:
-dry-run
don’t copy, just show what would be copied
-with-deps
follow dependencies when processing package-spec
CREATE LOCAL REPOSITORY
aptly repo create name [ from snapshot snapshot ]
Create local package repository. Repository would be empty when created, packages could be
added from files, copied or moved from another local repository or imported from the
mirror.
If local package repository is created from snapshot, repo initial contents are copied
from snapsot contents.
Example:
$ aptly repo create testing
$ aptly repo create mysql35 from snapshot mysql-35-2017
Options:
-comment=
any text that would be used to described local repository
-component=main
default component when publishing
-distribution=
default distribution when publishing
-uploaders-file=
uploaders.json to be used when including .changes into this repository
DELETE LOCAL REPOSITORY
aptly repo drop name
Drop information about deletions from local repo. Package data is not deleted (since it
could be still used by other mirrors or snapshots).
Example:
$ aptly repo drop local-repo
Options:
-force force local repo deletion even if used by snapshots
EDIT PROPERTIES OF LOCAL REPOSITORY
aptly repo edit name
Command edit allows one to change metadata of local repository: comment, default
distribution and component.
Example:
$ aptly repo edit -distribution=wheezy testing
Options:
-comment=
any text that would be used to described local repository
-component=
default component when publishing
-distribution=
default distribution when publishing
-uploaders-file=
uploaders.json to be used when including .changes into this repository
IMPORT PACKAGES FROM MIRROR TO LOCAL REPOSITORY
aptly repo import src-mirror dst-repo package-query ...
Command import looks up packages matching package-query in mirror src-mirror and copies
them to local repo dst-repo.
Example:
$ aptly repo import wheezy-main testing nginx
Options:
-dry-run
don’t import, just show what would be imported
-with-deps
follow dependencies when processing package-spec
LIST LOCAL REPOSITORIES
aptly repo list
List command shows full list of local package repositories.
Example:
$ aptly repo list
Options:
-json display list in JSON format
-raw display list in machine-readable format
MOVE PACKAGES BETWEEN LOCAL REPOSITORIES
aptly repo move src-name dst-name package-query ...
Command move moves packages matching package-query from local repo src-name to local repo
dst-name.
Example:
$ aptly repo move testing stable ’myapp (=0.1.12)’
Options:
-dry-run
don’t move, just show what would be moved
-with-deps
follow dependencies when processing package-spec
REMOVE PACKAGES FROM LOCAL REPOSITORY
aptly repo remove name package-query ...
Commands removes packages matching package-query from local repository name. If removed
packages are not referenced by other repos or snapshots, they can be removed completely
(including files) by running ’aptly db cleanup’.
Example:
$ aptly repo remove testing ’myapp (=0.1.12)’
Options:
-dry-run
don’t remove, just show what would be removed
SHOW DETAILS ABOUT LOCAL REPOSITORY
aptly repo show name
Show command shows full information about local package repository.
ex: $ aptly repo show testing
Options:
-json display record in JSON format
-with-packages
show list of packages
RENAMES LOCAL REPOSITORY
aptly repo rename old-name new-name
Command changes name of the local repo. Local repo name should be unique.
Example:
$ aptly repo rename wheezy-min wheezy-main
SEARCH REPO FOR PACKAGES MATCHING QUERY
aptly repo search name [package-query]
Command search displays list of packages in local repository that match package query
If query is not specified, all the packages are displayed.
Example:
$ aptly repo search my-software ’$Architecture (i386), Name (% *-dev)’
Options:
-format=
custom format for result printing
-with-deps
include dependencies into search results
ADD PACKAGES TO LOCAL REPOSITORIES BASED ON .CHANGES FILES
aptly repo include <file.changes>|directory ...
Command include looks for .changes files in list of arguments or specified directories.
Each .changes file is verified, parsed, referenced files are put into separate temporary
directory and added into local repository. Successfully imported files are removed by
default.
Additionally uploads could be restricted with <uploaders.json> file. Rules in this file
control uploads based on GPG key ID of .changes file signature and queries on .changes
file fields.
Example:
$ aptly repo include -repo=foo-release incoming/
Options:
-accept-unsigned
accept unsigned .changes files
-force-replace
when adding package that conflicts with existing package, remove existing package
-ignore-signatures
disable verification of .changes file signature
-keyring=
gpg keyring to use when verifying Release file (could be specified multiple times)
-no-remove-files
don’t remove files that have been imported successfully into repository
-repo={{.Distribution}}
which repo should files go to, defaults to Distribution field of .changes file
-uploaders-file=
path to uploaders.json file
CREATES SNAPSHOT OF MIRROR (LOCAL REPOSITORY) CONTENTS
aptly snapshot create name from mirror mirror-name | from repo repo-name | empty
Command create name from mirror makes persistent immutable snapshot of remote repository
mirror. Snapshot could be published or further modified using merge, pull and other aptly
features.
Command create name from repo makes persistent immutable snapshot of local repository.
Snapshot could be processed as mirror snapshots, and mixed with snapshots of remote
mirrors.
Command create name empty creates empty snapshot that could be used as a basis for
snapshot pull operations, for example. As snapshots are immutable, creating one empty
snapshot should be enough.
Example:
$ aptly snapshot create wheezy-main-today from mirror wheezy-main
LIST SNAPSHOTS
aptly snapshot list
Command list shows full list of snapshots created.
Example:
$ aptly snapshot list
Options:
-json display list in JSON format
-raw display list in machine-readable format
-sort=name
display list in ’name’ or creation ’time’ order
SHOWS DETAILS ABOUT SNAPSHOT
aptly snapshot show name
Command show displays full information about a snapshot.
Example:
$ aptly snapshot show wheezy-main
Options:
-json display record in JSON format
-with-packages
show list of packages
VERIFY DEPENDENCIES IN SNAPSHOT
aptly snapshot verify name [source ...]
Verify does dependency resolution in snapshot name, possibly using additional snapshots
source as dependency sources. All unsatisfied dependencies are printed.
Example:
$ aptly snapshot verify wheezy-main wheezy-contrib wheezy-non-free
PULL PACKAGES FROM ANOTHER SNAPSHOT
aptly snapshot pull name source destination package-query ...
Command pull pulls new packages along with its’ dependencies to snapshot name from
snapshot source. Pull can upgrade package version in name with versions from source
following dependencies. New snapshot destination is created as a result of this process.
Packages could be specified simply as ’package-name’ or as package queries.
Example:
$ aptly snapshot pull wheezy-main wheezy-backports wheezy-new-xorg xorg-server-server
Options:
-all-matches
pull all the packages that satisfy the dependency version requirements
-dry-run
don’t create destination snapshot, just show what would be pulled
-no-deps
don’t process dependencies, just pull listed packages
-no-remove
don’t remove other package versions when pulling package
DIFFERENCE BETWEEN TWO SNAPSHOTS
aptly snapshot diff name-a name-b
Displays difference in packages between two snapshots. Snapshot is a list of packages, so
difference between snapshots is a difference between package lists. Package could be
either completely missing in one snapshot, or package is present in both snapshots with
different versions.
Example:
$ aptly snapshot diff -only-matching wheezy-main wheezy-backports
Options:
-only-matching
display diff only for matching packages (don’t display missing packages)
MERGES SNAPSHOTS
aptly snapshot merge destination source [source...]
Merge command merges several source snapshots into one destination snapshot. Merge happens
from left to right. By default, packages with the same name-architecture pair are replaced
during merge (package from latest snapshot on the list wins). If run with only one source
snapshot, merge copies source into destination.
Example:
$ aptly snapshot merge wheezy-w-backports wheezy-main wheezy-backports
Options:
-latest
use only the latest version of each package
-no-remove
don’t remove duplicate arch/name packages
DELETE SNAPSHOT
aptly snapshot drop name
Drop removes information about a snapshot. If snapshot is published, it can’t be dropped.
Example:
$ aptly snapshot drop wheezy-main
Options:
-force remove snapshot even if it was used as source for other snapshots
RENAMES SNAPSHOT
aptly snapshot rename old-name new-name
Command changes name of the snapshot. Snapshot name should be unique.
Example:
$ aptly snapshot rename wheezy-min wheezy-main
SEARCH SNAPSHOT FOR PACKAGES MATCHING QUERY
aptly snapshot search name [package-query]
Command search displays list of packages in snapshot that match package query
If query is not specified, all the packages are displayed.
Example:
$ aptly snapshot search wheezy-main ’$Architecture (i386), Name (% *-dev)’
Options:
-format=
custom format for result printing
-with-deps
include dependencies into search results
FILTER PACKAGES IN SNAPSHOT PRODUCING ANOTHER SNAPSHOT
aptly snapshot filter source destination package-query ...
Command filter does filtering in snapshot source, producing another snapshot destination.
Packages could be specified simply as ’package-name’ or as package queries.
Example:
$ aptly snapshot filter wheezy-main wheezy-required ’Priority (required)’
Options:
-with-deps
include dependent packages as well
REMOVE PUBLISHED REPOSITORY
aptly publish drop distribution [[endpoint:]prefix]
Command removes whatever has been published under specified prefix, publishing endpoint
and distribution name.
Example:
$ aptly publish drop wheezy
Options:
-force-drop
remove published repository even if some files could not be cleaned up
-skip-cleanup
don’t remove unreferenced files in prefix/component
LIST OF PUBLISHED REPOSITORIES
aptly publish list
Display list of currently published snapshots.
Example:
$ aptly publish list
Options:
-json display list in JSON format
-raw display list in machine-readable format
PUBLISH LOCAL REPOSITORY
aptly publish repo name [[endpoint:]prefix]
Command publishes current state of local repository ready to be consumed by apt tools.
Published repostiories appear under rootDir/public directory. Valid GPG key is required
for publishing.
Multiple component repository could be published by specifying several components split by
commas via -component flag and multiple local repositories as the arguments:
aptly publish repo -component=main,contrib repo-main repo-contrib
It is not recommended to publish local repositories directly unless the repository is for
testing purposes and changes happen frequently. For production usage please take snapshot
of repository and publish it using publish snapshot command.
Example:
$ aptly publish repo testing
Options:
-acquire-by-hash
provide index files by hash
-batch run GPG with detached tty
-butautomaticupgrades=
set value for ButAutomaticUpgrades field
-component=
component name to publish (for multi-component publishing, separate components with
commas)
-distribution=
distribution name to publish
-force-overwrite
overwrite files in package pool in case of mismatch
-gpg-key=
GPG key ID to use when signing the release
-keyring=
GPG keyring to use (instead of default)
-label=
label to publish
-notautomatic=
set value for NotAutomatic field
-origin=
origin name to publish
-passphrase=
GPG passphrase for the key (warning: could be insecure)
-passphrase-file=
GPG passphrase-file for the key (warning: could be insecure)
-secret-keyring=
GPG secret keyring to use (instead of default)
-skip-contents
don’t generate Contents indexes
-skip-signing
don’t sign Release files with GPG
-suite=
suite to publish (defaults to distribution)
PUBLISH SNAPSHOT
aptly publish snapshot name [[endpoint:]prefix]
Command publishes snapshot as Debian repository ready to be consumed by apt tools.
Published repostiories appear under rootDir/public directory. Valid GPG key is required
for publishing.
Multiple component repository could be published by specifying several components split by
commas via -component flag and multiple snapshots as the arguments:
aptly publish snapshot -component=main,contrib snap-main snap-contrib
Example:
$ aptly publish snapshot wheezy-main
Options:
-acquire-by-hash
provide index files by hash
-batch run GPG with detached tty
-butautomaticupgrades=
overwrite value for ButAutomaticUpgrades field
-component=
component name to publish (for multi-component publishing, separate components with
commas)
-distribution=
distribution name to publish
-force-overwrite
overwrite files in package pool in case of mismatch
-gpg-key=
GPG key ID to use when signing the release
-keyring=
GPG keyring to use (instead of default)
-label=
label to publish
-notautomatic=
overwrite value for NotAutomatic field
-origin=
overwrite origin name to publish
-passphrase=
GPG passphrase for the key (warning: could be insecure)
-passphrase-file=
GPG passphrase-file for the key (warning: could be insecure)
-secret-keyring=
GPG secret keyring to use (instead of default)
-skip-contents
don’t generate Contents indexes
-skip-signing
don’t sign Release files with GPG
-suite=
suite to publish (defaults to distribution)
UPDATE PUBLISHED REPOSITORY BY SWITCHING TO NEW SNAPSHOT
aptly publish switch distribution [[endpoint:]prefix] new-snapshot
Command switches in-place published snapshots with new snapshot contents. All publishing
parameters are preserved (architecture list, distribution, component).
For multiple component repositories, flag -component should be given with list of
components to update. Corresponding snapshots should be given in the same order, e.g.:
aptly publish switch -component=main,contrib wheezy wh-main wh-contrib
Example:
$ aptly publish switch wheezy ppa wheezy-7.5
This command would switch published repository (with one component) named ppa/wheezy
(prefix ppa, dsitribution wheezy to new snapshot wheezy-7.5).
Options:
-batch run GPG with detached tty
-component=
component names to update (for multi-component publishing, separate components with
commas)
-force-overwrite
overwrite files in package pool in case of mismatch
-gpg-key=
GPG key ID to use when signing the release
-keyring=
GPG keyring to use (instead of default)
-passphrase=
GPG passphrase for the key (warning: could be insecure)
-passphrase-file=
GPG passphrase-file for the key (warning: could be insecure)
-secret-keyring=
GPG secret keyring to use (instead of default)
-skip-cleanup
don’t remove unreferenced files in prefix/component
-skip-contents
don’t generate Contents indexes
-skip-signing
don’t sign Release files with GPG
UPDATE PUBLISHED LOCAL REPOSITORY
aptly publish update distribution [[endpoint:]prefix]
Command re-publishes (updates) published local repository. distribution and prefix should
be occupied with local repository published using command aptly publish repo. Update
happens in-place with minimum possible downtime for published repository.
For multiple component published repositories, all local repositories are updated.
Example:
$ aptly publish update wheezy ppa
Options:
-batch run GPG with detached tty
-force-overwrite
overwrite files in package pool in case of mismatch
-gpg-key=
GPG key ID to use when signing the release
-keyring=
GPG keyring to use (instead of default)
-passphrase=
GPG passphrase for the key (warning: could be insecure)
-passphrase-file=
GPG passphrase-file for the key (warning: could be insecure)
-secret-keyring=
GPG secret keyring to use (instead of default)
-skip-cleanup
don’t remove unreferenced files in prefix/component
-skip-contents
don’t generate Contents indexes
-skip-signing
don’t sign Release files with GPG
SHOWS DETAILS OF PUBLISHED REPOSITORY
aptly publish show distribution [[endpoint:]prefix]
Command show displays full information of a published repository.
Example:
$ aptly publish show wheezy
Options:
-json display record in JSON format
SEARCH FOR PACKAGES MATCHING QUERY
aptly package search [package-query]
Command search displays list of packages in whole DB that match package query.
If query is not specified, all the packages are displayed.
Example:
$ aptly package search ’$Architecture (i386), Name (% *-dev)’
Options:
-format=
custom format for result printing
SHOW DETAILS ABOUT PACKAGES MATCHING QUERY
aptly package show package-query
Command shows displays detailed meta-information about packages matching query.
Information from Debian control file is displayed. Optionally information about package
files and inclusion into mirrors/snapshots/local repos is shown.
Example:
$ aptly package show ’nginx-light_1.2.1-2.2+wheezy2_i386’
Options:
-with-files
display information about files from package pool
-with-references
display information about mirrors, snapshots and local repos referencing this
package
CLEANUP DB AND PACKAGE POOL
aptly db cleanup
Database cleanup removes information about unreferenced packages and removes files in the
package pool that aren’t used by packages anymore
Example:
$ aptly db cleanup
Options:
-dry-run
don’t delete anything
-verbose
be verbose when loading objects/removing them
RECOVER DB AFTER CRASH
aptly db recover
Database recover does its’ best to recover the database after a crash. It is recommended
to backup the DB before running recover.
Example:
$ aptly db recover
HTTP SERVE PUBLISHED REPOSITORIES
aptly serve
Command serve starts embedded HTTP server (not suitable for real production usage) to
serve contents of public/ subdirectory of aptly’s root that contains published
repositories.
Example:
$ aptly serve -listen=:8080
Options:
-listen=:8080
host:port for HTTP listening
START API HTTP SERVICE
aptly api serve
Start HTTP server with aptly REST API. The server can listen to either a port or Unix
domain socket. When using a socket, Aptly will fully manage the socket file. This command
also supports taking over from a systemd file descriptors to enable systemd socket
activation.
Example:
$ aptly api serve -listen=:8080 $ aptly api serve -listen=unix:///tmp/aptly.sock
Options:
-listen=:8080
host:port for HTTP listening or unix://path to listen on a Unix domain socket
-no-lock
don’t lock the database
RENDER GRAPH OF RELATIONSHIPS
aptly graph
Command graph displays relationship between mirrors, local repositories, snapshots and
published repositories using graphviz package to render graph as an image.
Example:
$ aptly graph
Options:
-format=png
render graph to specified format (png, svg, pdf, etc.)
-layout=horizontal
create a more ’vertical’ or a more ’horizontal’ graph layout
-output=
specify output filename, default is to open result in viewer
SHOW CURRENT APTLY’S CONFIG
aptly config show
Command show displays the current aptly configuration.
Example:
$ aptly config show
RUN APTLY TASKS
aptly task run -filename=filename | command1, command2, ...
Command helps organise multiple aptly commands in one single aptly task, running as single
thread.
Example:
$ aptly task run
> repo create local
> repo add local pkg1
> publish repo local
> serve
>
Options:
-filename=
specifies the filename that contains the commands to run
SHOW CURRENT APTLY’S CONFIG
aptly config show
Command show displays the current aptly configuration.
Example:
$ aptly config show
ENVIRONMENT
If environment variable HTTP_PROXY is set aptly would use its value to proxy all HTTP
requests.
RETURN VALUES
aptly exists with:
0 success
1 general failure
2 command parse failure
AUTHORS
List of contributors, in chronological order:
○ Andrey Smirnov (https://github.com/smira)
○ Sebastien Binet (https://github.com/sbinet)
○ Ryan Uber (https://github.com/ryanuber)
○ Simon Aquino (https://github.com/queeno)
○ Vincent Batoufflet (https://github.com/vbatoufflet)
○ Ivan Kurnosov (https://github.com/zerkms)
○ Dmitrii Kashin (https://github.com/freehck)
○ Chris Read (https://github.com/cread)
○ Rohan Garg (https://github.com/shadeslayer)
○ Russ Allbery (https://github.com/rra)
○ Sylvain Baubeau (https://github.com/lebauce)
○ Andrea Bernardo Ciddio (https://github.com/bcandrea)
○ Michael Koval (https://github.com/mkoval)
○ Alexander Guy (https://github.com/alexanderguy)
○ Sebastien Badia (https://github.com/sbadia)
○ Szymon Sobik (https://github.com/sobczyk)
○ Paul Krohn (https://github.com/paul-krohn)
○ Vincent Bernat (https://github.com/vincentbernat)
○ x539 (https://github.com/x539)
○ Phil Frost (https://github.com/bitglue)
○ Benoit Foucher (https://github.com/bentoi)
○ Geoffrey Thomas (https://github.com/geofft)
○ Oliver Sauder (https://github.com/sliverc)
○ Harald Sitter (https://github.com/apachelogger)
○ Johannes Layher (https://github.com/jola5)
○ Charles Hsu (https://github.com/charz)
○ Clemens Rabe (https://github.com/seeraven)
○ TJ Merritt (https://github.com/tjmerritt)
○ Matt Martyn (https://github.com/MMartyn)
○ Ludovico Cavedon (https://github.com/cavedon)
○ Petr Jediny (https://github.com/pjediny)
○ Maximilian Stein (https://github.com/steinymity)
○ Strajan Sebastian (https://github.com/strajansebastian)
○ Artem Smirnov (https://github.com/urpylka)
○ William Manley (https://github.com/wmanley)
○ Shengjing Zhu (https://github.com/zhsj)
○ Nabil Bendafi (https://github.com/nabilbendafi)
○ Raphael Medaer (https://github.com/rmedaer)
○ Raul Benencia (https://github.com/rul)
○ Don Kuntz (https://github.com/dkuntz2)
○ Joshua Colson (https://github.com/freakinhippie)
○ Andre Roth (https://github.com/neolynx)
○ Lorenzo Bolla (https://github.com/lbolla)
○ Benj Fassbind (https://github.com/randombenj)
January 2022 APTLY(1)