80 lines
2.3 KiB
Markdown
80 lines
2.3 KiB
Markdown
|
Package workflow
|
||
|
|
================
|
||
|
|
|
||
|
|
When it comes to creating, maintaining, and building packages in Devuan,
|
||
|
|
there is a standardized workflow that has been used so far. All of
|
||
|
|
Devuan's official packages reside in the `devuan-packages` namespace on
|
||
|
|
our [GitLab](https://git.devuan.org) instance. Once a package is being
|
||
|
|
maintained under this namespace, it can be considered usable and ready
|
||
|
|
to build.
|
||
|
|
|
||
|
|
A Devuan package's `debian` directory should be maintained the same way
|
||
|
|
like any other Debian package, with the possible exception of `gbp.conf`.
|
||
|
|
In `gbp.conf` we have to set up the upstream tag for the tag we are
|
||
|
|
planning to build. An example gbp.conf file looks like:
|
||
|
|
|
||
|
|
```
|
||
|
|
[DEFAULT]
|
||
|
|
upstram-tag = %(version)s
|
||
|
|
```
|
||
|
|
|
||
|
|
This helps jenkins-debian-glue, and more specifically - pbuilder - to
|
||
|
|
figure out what to do with the git repository and how to build the
|
||
|
|
package.
|
||
|
|
|
||
|
|
In Devuan, we maintain many different suites, like `ascii-proposed`,
|
||
|
|
`ascii-updates`, `ascii-proposed`, etc. All of these are then supposed
|
||
|
|
to be maintained in different branches, that are named like this, with
|
||
|
|
the additional prefix of `suites/`, so an example branch would be:
|
||
|
|
`suites/ascii`. The package in this git repository under this branch
|
||
|
|
would then be build and it would end up in the ascii suite.
|
||
|
|
|
||
|
|
|
||
|
|
An example workflow
|
||
|
|
-------------------
|
||
|
|
|
||
|
|
In shell commands, introducing a package into Devuan would look like the
|
||
|
|
following:
|
||
|
|
|
||
|
|
```
|
||
|
|
$ git clone myproject.git
|
||
|
|
$ cd myproject
|
||
|
|
|
||
|
|
## Then add a debian directory and fill up the needed information
|
||
|
|
|
||
|
|
$ git checkout -b suites/ascii
|
||
|
|
|
||
|
|
$ git tag 0.1
|
||
|
|
|
||
|
|
## Set up remote for pushing to git.devuan.org
|
||
|
|
|
||
|
|
$ git push --tags
|
||
|
|
```
|
||
|
|
|
||
|
|
This would get a package ready for building.
|
||
|
|
|
||
|
|
|
||
|
|
Following up, we need to get it on the Jenkins CI...
|
||
|
|
|
||
|
|
### Pushing to Jenkins
|
||
|
|
|
||
|
|
Once we have our package ready in the `devuan-packages` namespace, we
|
||
|
|
push it to Jenkins by opening a Gitlab issue:
|
||
|
|
|
||
|
|
* Title: `buildadd`
|
||
|
|
* Assignee: `@autobuild`
|
||
|
|
* Labels: `any`
|
||
|
|
|
||
|
|
(The labels here correspond to CPU architectures).
|
||
|
|
|
||
|
|
After opening the issue, in a matter of minutes, a bot will scan the
|
||
|
|
issue, create corresponding jobs on Jenkins, and close your issue,
|
||
|
|
commenting its progress and end result.
|
||
|
|
|
||
|
|
To build your package, open another issue:
|
||
|
|
|
||
|
|
* Title: `build:
|
||
|
|
* Assignee: `@autobuild`
|
||
|
|
|
||
|
|
And again, in a matter of minutes, you package should start building.
|