aptly - Debian repository management tool
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
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.
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)
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
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:
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:
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)’
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
- -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)
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)
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-
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
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)
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
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
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
aptly config show
Command show displays the current aptly configuration.
Example:
$ aptly config show
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
aptly config show
Command show displays the current aptly configuration.
Example:
$ aptly config show
If environment variable
HTTP_PROXY is set
aptly would use its
value to proxy all HTTP requests.
aptly exists with:
- 0
- success
- 1
- general failure
- 2
- command parse failure
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)
-
-