mirror of
https://github.com/ublue-os/packages.git
synced 2026-11-03 21:49:48 -09:00
0f13e36ace
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: castrojo <1264109+castrojo@users.noreply.github.com>
89 lines
4.7 KiB
Markdown
89 lines
4.7 KiB
Markdown
# Universal Blue RPM specs
|
|
|
|
[](https://deepwiki.com/ublue-os/packages)
|
|
|
|
Packages for Universal Blue projects.
|
|
|
|
We use this repository as the base for [multiple Universal Blue COPRs](https://copr.fedorainfracloud.org/coprs/ublue-os)
|
|
each one with their own purpose defined on their [READMEs](./packages/README.md).
|
|
|
|
You can build any package by running our custom builder container, it should fetch the sources and do everything for you.
|
|
It mounts `mock/` on the current directory so that you can get the resulting RPMs/SRPMs and check the resulting chroots
|
|
|
|
```bash
|
|
# You can specify whatever chroot you want to use, usually those that are supported on COPR should work
|
|
just build $PATH_TO_SPEC $ARGUMENTS_FOR_MOCK
|
|
|
|
# This builds devpod on the Fedora version that the builder container is on (F41)
|
|
just build ./staging/devpod/devpod.spec
|
|
|
|
# This builds devpod on the CentOS Stream + EPEL 10 chroot
|
|
just build ./staging/devpod/devpod.spec -r epel-10-$(arch)
|
|
|
|
# You can also compile for other architectures by passing --forcearch if you have qemu-user-static on your host system
|
|
just build ./staging/devpod/devpod.spec --forcearch=aarch64
|
|
```
|
|
|
|
## Contributing
|
|
|
|
### New package
|
|
|
|
When adding a new package certain guidelines should be followed, usually try to stick to the [Fedora Packaging Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/)
|
|
for all packages (with case-by-case exceptions). `rpmlint` should always pass ([rpkg](https://docs.pagure.org/rpkg-util/v3/quick_start.html)-based packages are an exception),
|
|
they should always be buildable offline once all sources are fetched (so that they can be built on GitHub actions/[mock](https://rpm-software-management.github.io/mock/)),
|
|
and always make sure that [Renovate](https://github.com/renovatebot/renovate) can automatically update your package, we have [macros on this repo](./.github/renovate.json5).
|
|
|
|
Once merged, your new package will need to be manually added to its corresponding COPR ([file in an issue](https://github.com/ublue-os/packages/issues) if it hasn't
|
|
been added in a week or so) and then it should be automatically rebuilt over time.
|
|
|
|
### Existing package
|
|
|
|
Make sure your contribution passes linting and the guidelines required by [the New Package section](#new-package). Bump the package accordingly:
|
|
- If the package has sources on this repo, bump the `Version:` field;
|
|
- If it has external sources, bump the spec `Release:` field (you can/should do it via `rpmdev-bumpspec` ideally).
|
|
|
|
#### Bumping Package Versions
|
|
|
|
When updating an existing package, you need to bump either the `Version` or `Release` field depending on the source of the changes:
|
|
|
|
**Version Field Bumping** - Use when the upstream software has a new version:
|
|
- For packages with sources in this repository, increment the `Version:` field
|
|
- Example from `bluefin/fedora-logos/fedora-logos.spec`:
|
|
```spec
|
|
Name: fedora-logos
|
|
Version: 100.0.0 # <- Bump this when updating branding assets
|
|
Release: 4%{?dist}
|
|
```
|
|
|
|
**Release Field Bumping** - Use when making packaging changes without upstream version changes:
|
|
- For packages with external sources, increment the `Release:` field
|
|
- Use `rpmdev-bumpspec` for proper formatting and changelog entries
|
|
- Example workflow:
|
|
```bash
|
|
# Automatic release bump with changelog entry
|
|
rpmdev-bumpspec path/to/package.spec
|
|
|
|
# Manual release bump (if rpmdev-bumpspec is not available)
|
|
# Change: Release: 1%{?dist}
|
|
# To: Release: 2%{?dist}
|
|
```
|
|
|
|
**Best Practices:**
|
|
- Always use `rpmdev-bumpspec` when possible for proper changelog management
|
|
- Reset `Release` to 1 when bumping `Version`
|
|
- Include meaningful changelog entries describing your changes
|
|
- For complex packages, check if they use `%autorelease` or `%global baserelease` patterns
|
|
|
|
### For maintainers/approvers
|
|
|
|
Make sure all the PRs are safe, as in they don't have [RCE](https://www.cloudflare.com/learning/security/what-is-remote-code-execution/)
|
|
exploits or any abuse of GitHub actions (or similar). When you are sure of that, put the `safe-to-run` tag on the target
|
|
pull request and let it run. Sometimes some packages will require the runner to have an online connection and that isn't
|
|
implemented yet so you might want to review the commits on your local machine and make sure they build correctly with a network connection.
|
|
|
|
You can create a testing distrobox by running `distrobox create --name testingbox --image ghcr.io/ublue-os/ublue-builder`
|
|
or by running `just build` from the locally cloned fork, it should be exactly the same environment as the GitHub actions use for building.
|
|
|
|
## Metrics
|
|
|
|
|