NOTE: This is an experimental feature and is subject to change!
What’s this about?
To improve the snapcraft workflow for snaps requiring non-standard repositories (such as PPAs, additional repository components, etc.), apt repository configuration via snapcraft.yaml
is now available experimentally!
The syntax developed here tried to balance:
- previous consensus at Proposal: additional package sources - #23 by cjp256
- cloud-init’s well-established syntax at https://cloudinit.readthedocs.io/en/latest/topics/modules.html#apt-configure
- simple and extensible schema for validation
Other interesting syntax includes:
How do I test it?
It’s currently available in snapcraft’s edge/pr-2911
channel!
To update snapcraft to this experimental build, use:
sudo snap refresh snapcraft --channel=edge/pr-2911
GitHub PR: https://github.com/snapcore/snapcraft/pull/2911
How do I configure it?
package-management
This feature adds a high-level key package-management
to snapcraft.yaml that enables users to configure additional repositories & components. Specifically, the scope of package-management
is for anything affecting the behavior and availability of:
- build-packages
- stage-packages
- build-snaps
- stage-snaps
- python-packages (related note: python-packages should probably be decoupled into build & stage)
package-management.repositories
Under package-management
is the repositories
property, a list of repository
configs that you would like snapcraft to install and configure. Once configured, packages provided by these repositories will become available via stage-packages
and build-packages
.
Repositories have the following properties:
- source
- gpg-public-key
- gpg-public-key-id
- gpg-key-server
repository.source (required)
String specifying source repository URI components. Supports the following syntax supported by add-apt-repository
:
-
short-form PPAs, e.g.:
- source: ppa:cjp256/test-ppa
- source: ppa:mozillateam/ppa
-
traditional deb repository line for sources.list, with format
deb <url> <suite> <components...>
, e.g.:- source: deb Index of /ubuntu bionic partner
- source: deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main
-
repository URI, with suite assumed to match host (such as “bionic” for core18 / 18.04 build environment) and optional component defaulting to “main”, e.g.:
- source: Index of /ubuntu partner
- source: Index of /cjp256/test-ppa/ubuntu
repository.gpg-public-key
String specifying full ASCII-armored public key. Must include the PGP header/footer, e.g.:
gpg-public-key: |
-----BEGIN PGP PUBLIC KEY BLOCK-----
<snipped>
-----END PGP PUBLIC KEY BLOCK-----
repository.gpg-public-key-id
String specifying the GPG public key identifier/fingerpint to fetch from a key server, e.g.:
gpg-public-key-id: 590CA3D8E4826565BE3200526A634116E00F4C82
repository.gpg-key-server
String specifying the key server to use for fetching GPG key (specified by gpg-public-key-id
). Defaults to keyserver.ubuntu.com. E.g.:
gpg-public-key-id: 590CA3D8E4826565BE3200526A634116E00F4C82
gpg-key-server: keyserver.ubuntu.com
TLDR; Examples
Here are some examples to help get you started!
package-management:
repositories:
# Option 1: PPA shortcut (automatically imports PPA key from LP):
- source: ppa:cjp256/test-ppa
# Option 2: Enable apt repository via "deb" sources.list format using OS-installed keys:
- source: deb http://archive.canonical.com/ubuntu bionic partner
# Option 3: Enable repository with specified component using OS-installed keys:
- source: http://archive.canonical.com/ubuntu partner
# Option 4: Use repository with GPG key fetched from keyserver:
- source: http://ppa.launchpad.net/cjp256/test-ppa/ubuntu
gpg-public-key-id: 6A634116E00F4C82
gpg-key-server: keyserver.ubuntu.com
# Option 5: Use repository with provided GPG key:
- source: http://ppa.launchpad.net/cjp256/test-ppa/ubuntu
gpg-public-key: |
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF4y3MIBEAC6rYxrDtleK/OPftHKySm5nN8OIc+tBFnGr9pz4eu2CRukFxXc
Ap07pj5EkRbzI60BeGVK/spLFtrU7PPxBXJ3DiaxEaWmOUW/7MdukSWTVk9EgEAZ
dwKjbwNrrxmCif8RJzK9JFz1IqGqY/uzR7X90J2Wn4/+FvWNofE2kCQeGEpDQtmF
bpcBdHZmcru8g/t3KQy11i4GJ5gLXqFdDF3T3YcVgLyoOx910VK0Y41Rsux7PwlR
PmF3doZ+fjLBYVBo0l5ek56dc7p1Z6RL30IHgbwdSbDcYJ8d8dXR+gFUuB4xSYTk
XRD2Uzc+jDcwXEaTGFvxQNxIXW4ELwwB5ceqbt/l1w4Yo+pQrSKDjOeG80kwRWsw
bGnaAEa8ZKMHvQdr6wIGwiD6LfNAKGtr5xw4O7VzalF6KuzmrRt9RQc/bkso3DQV
tCC/nkI55gXEM6zH3NiGQiz47SrjENXWOwJvGrBT36eHCsLZ984SwRHCOqubEAwE
G7mkRcew/YC2xe6ic7ZMxVQ3DkmHKojO3qoS73KbuRgp6xwcBXxtPN2k/rAEmVTz
aXIPp46mXbwAfcuo5gFRknGzgyOP8cG5KMbl/AGJjRRfiWlIC5RmCcguGsgC5p0n
4cPX7+u0J9+pjyPdOntSm5WS1+2HYkd7vS0Qmio5/e7Sw1blCai1mxc7rQARAQAB
tCFMYXVuY2hwYWQgUFBBIGZvciBDaHJpcyBQYXR0ZXJzb26JAjgEEwECACIFAl4y
3MICGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGpjQRbgD0yCanYP/001
tx9sgjfGCsA2WNbHAcoqN5Di1dIo4js5inFHWhFFDte4qY1uAx3lKxpq5iyqzwtB
rN/fbp3URd+ZqsVQ8IkfPf+lzMubf9YnKxbuBeXU+y5Kj8pmoL6sCpieobk9+3Go
rtAkrlmFw7GmpPeCzaHhr5YzOO82T75EEb2a6FYduPv+ONGJqk8P2f20CzlK84ze
G6ApSD7BdZ70iUvC0oy6AJoU8uSgoOfMdTIgT7NWXLfqzOIo+Fy5dlnmGS09y132
hpjqvx3VCFdGH+NSfcmEVCTcLnqoPqD6InXoROqi30c2D4PmX2h1Endac6BF9uCB
xdFBb8SKZ7mJ/dydAEV9KbUr+mQCAG5JO0+GnxgtKanHjMmDcF9BtmHMZsKDjILs
7iyiWEsrk+QsUpV5gxOdpOFvL2FfSVTTYhmKgCI9h+KqesAPnJwIhCI5Gz94MaYo
V8T+4ZjX36DNh5f7gzWLvajvKznOXGJkX6TgbqFo/wrijK75DPmuuR7m2Xa4AlAT
J0JZFdHWXuJnYI3vSZ2OfgHJKsLePheLFtJvpFJTPC0nOFwWgg2JH//UDbEIk5md
nLQl+agC5z32g+Qet+D/5y+xamJP/5HKgix8RhggPSIsaMi8ezNrF08jyollwDFk
c24ABjaDjM0uWKllldFtmpnW7V0tOFxm+RIA6dCM
=ulGo
-----END PGP PUBLIC KEY BLOCK-----
As always, feedback and suggestions are appreciated! If you test this out and discover any bugs, please let us know. If you test this out and it works great, that’s good to know too
In-progress Discussion Points / Open Questions
These considerations are not reflected in the PR
-
Rename
repositories
toapt.repositories
based on @niemeyer’s feedback that sources are likely to be apt-specific. It is agreed the safest option would be to just make it apt-specific decouple the schema for future bases. Though it does require an additional layer of nesting to maintain a list without preventing future expansion of other configuration keys.Previously it was assumed that the repositories would be parsed in the context of the
base
in which they are building.For reference, the original EPEL example in a hypothetical future where
base: centos
exists:
- source: http://download.fedoraproject.org/pub/epel/testing/8/$basearch
gpg-public-key: |
-----BEGIN PGP PUBLIC KEY BLOCK-----
<snipped>
-----END PGP PUBLIC KEY BLOCK-----
-
Rename
source
to ?? based on @niemeyer’s feedback thatsource
may be confused with other context of “source”.Data points to consider:
-
source
is used bycloud-init
-
repo
is used byansible
-
source
is used in snapcraft’spart
configuration to point to a source repository
-
-
Remove
package-mangement
and push keys to higher level? @niemeyerSome hypothetical keys to consider to support future configuration:
package-mangement:
apt:
repositories:
- ...
- ...
pip:
index-url: <index-url>
extra-index-urls:
- <extra-index-url>
- <extra-index-url2>
snap:
store-id: <UBUNTU_STORE_ID>
Being able to configure the snap store ID is part of a story to improve the snapcraft builds for brand store users. Bug #1833220 “stage-snaps not usable with a brand store” : Bugs : Snapcraft