Repository for Bottles components
With a centralized repository we can provide some data such as the checksum, which is useful for validate downloads.
To propose new components, it is necessary to open a Pull Request with the manifest of the component we want to add, here are some examples of manifest:
To do it, there is currently two methods.
For most components, new stable versions (and experimental builds if they exist) are automatically pulled. This is accomplished by the pull-components.yml workflow, where components are described in the following format:
repo : "doitsujin/dxvk",
workflow: "artifacts.yml",
branch: "master",
name-prefix: "dxvk-",
version-prefix: "v",
yaml-file: "14-dxvk.yml"
Category: "dxvk",
Sub-category: "",
where:
- repo is the GitHub repository in the format
owner/repository
- workflow is the workflow filename used to generate exerimental builds, if any
- branch is the workflow branch used to generate exerimental builds, if any
- name-prefix is used to generate the full name of the component using name-prefix +
version
(e.g.dxvk-
+2.0
), and look for release/experimental asset whose filename is begining by name-prefix - version-prefix is used to find the latest release version whose tag is begining by version-prefix, and to remove version-prefix from the final
version
string (e.g.v2.0
will become2.0
) - yaml-file is the YAML component filename located in the input_files directory
- Category and Sub-category are repectively the Category and Sub-category as described in the yaml-file (e.g. 14-dxvk.yml)
Each poster must follow the following layout:
Name: caffe-7.2
Provider: bottles
Channel: stable
File:
- file_name: caffe-7.2-x86_64.tar.xz
url: https://github.com/bottlesdevs/wine/releases/download/caffe-7.2/caffe-7.2-x86_64.tar.xz
file_checksum: 659ee0ee3dbe5274825734ad19692e12
rename: caffe-7.2-x86_64.tar.xz
old json manifests can be converted using this online tool.
where:
- Name is a name without spaces, including version, of the component (must reflect the name of the manifest file)
- Provider is the name of the component supplier (not the maintainer)
- Channel should be stable or unstable
- File is where it is stated how to get the component archive
- file_name is the full name of the component archive
- url is the direct URL to the archive download (only tarball are supported)
- file_checksum is the MD5 checksum of the archive
- rename this field should be the same as the name of the component for must cases (plus the extension), it is needed to rename the archive.
There is also an optional Post
section, which can be used to rename the path after extraction:
Post:
- action: rename
source: lutris-fshack-6.14-2
dest: lutris-6.14-2-fshack
We provide an automatic tools for generating the manifest. Please double check and test the manfiest before open a pull request.
The sources of the components must be public and searchable and must not infringe any copyright. Also, each archive must contain the compiled version and not the source code.
There is also a testing repository to test components before publishing them to the main repository.
To do so you need to add the new component to the testing.yml
file (opening a Pull request) and run bottles with the environment variable TESTING_REPOS=1
to use the testing repository.