Drop repoman in favour of pkgcheck/pkgdev

As per discussed in [1]

[1] https://archives.gentoo.org/gentoo-dev/message/93df9e7a2ad9d8d33e0cc83b50556d51

Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
This commit is contained in:
Andrew Ammerlaan
2022-04-04 16:47:08 +02:00
parent 01e3efd5b8
commit 0fa19ebeb3
4 changed files with 4 additions and 61 deletions

View File

@@ -1,19 +0,0 @@
name: repoman
on:
push:
branches: [ dev ]
pull_request:
branches: [ dev ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup master gentoo repository
run: |
./scripts/setup-master-gentoo.sh
- name: Setup and run Repoman
run: |
./scripts/setup-and-run-repoman.sh

View File

@@ -14,15 +14,15 @@ Please don't put Gentoo projects (e.g. the proxy-maint project) in the metadata.
When moving a package from a Pull Request in the [main Gentoo Repository](https://github.com/gentoo/gentoo) to GURU it is easy to forget to remove the [proxy-maint](https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers) project from the metadata.xml file. The same is true for moving from GURU to a ::gentoo Pull Request, if you forget to add proxy-maint to the metadata file the `gentoo-repo-qa-bot` will complain.
- #### Use repoman for committing
- #### Use pkgcheck for double checking your ebuilds and use pkgdev for committing
`repoman ci` is strongly preferred over `git commit -S` for committing, because [repoman](https://wiki.gentoo.org/wiki/Repoman) does additional checks and regenerates the manifest before committing. Sometimes committing with repoman is not possible (e.g. when committing eclasses or removing packages), in these cases there is no other possibility but to revert to `git commit -S`. In all other cases it is good practice to use repoman.
`pkgcheck scan --net` (for QA run) and `pkgdev commit` (for committing) is strongly preferred over a direct `git commit -S`, because [pkgdev](https://blogs.gentoo.org/mgorny/2019/12/12/a-better-ebuild-workflow-with-pure-git-and-pkgcheck/) does additional checks and regenerates the manifest before committing. Sometimes committing with pkgdev is not possible (e.g. when committing eclasses or removing packages), in these cases there is no other possibility but to revert to `git commit -S`. In all other cases it is good practice to use pkgcheck and pkgdev.
In GURU we use ['thin manifests'](https://wiki.gentoo.org/wiki/Repository_format/package/Manifest#Thin_Manifest). Because this is not the default, manifest files should be regenerated when moving a package from another overlay that does not use thin manifests (including your [local overlay](https://wiki.gentoo.org/wiki/Custom_repository) unless it is also configured to use thin manifests).
- #### Quote your variables
String variables should be quoted (e.g. not `$P` or `${P}` but `"${P}"`). `repoman -dx full` will warn you about any unquoted variables you might have forgotten about.
String variables should be quoted (e.g. not `$P` or `${P}` but `"${P}"`). `pkgcheck scan` will warn you about any unquoted variables you might have forgotten about.
- #### Run tests if you enable them
@@ -36,7 +36,7 @@ Please don't use symlinks in the repository (e.g. foobar-x.y.z.ebuild -> foobar-
- #### Undesirable/Deprecated dependencies
Sometimes a upstream lists dependencies which are considered deprecated. If possible, packages should **not** depend on these deprecated dependencies. Reasons a dependency might be deprecated is that it is too old, unmaintained, or the features it adds are not useful to Gentoo. You can find an overview of the currently deprecated dependencies and the reason they are deprecated in `$(portageq get_repo_path / gentoo)/profiles/package.deprecated`. `repoman -dx full` will warn you if your package depends on a deprecated dependency.
Sometimes a upstream lists dependencies which are considered deprecated. If possible, packages should **not** depend on these deprecated dependencies. Reasons a dependency might be deprecated is that it is too old, unmaintained, or the features it adds are not useful to Gentoo. You can find an overview of the currently deprecated dependencies and the reason they are deprecated in `$(portageq get_repo_path / gentoo)/profiles/package.deprecated`. `pkgcheck scan` will warn you if your package depends on a deprecated dependency.
For Python packages there are some additional (test) dependencies that are considered undesirable or not useful, but are not considered deprecated. You can find an overview of those [here](https://projects.gentoo.org/python/guide/distutils.html#enabling-tests) and in the list below:
```
@@ -78,12 +78,6 @@ The xdg eclass will automatically export the correct functions to the `src_prepa
Since the packages in GURU are all 'new packages' (not in ::gentoo). It is good practice to use the latest [EAPI](https://devmanual.gentoo.org/ebuild-writing/eapi/index.html) (8 at the moment), this makes your ebuilds more future proof.
- #### `repoman -dx full` and `pkgcheck scan`
Running `repoman -dx full` in the directory your ebuild is in will preform some basic checks on your ebuild. Please try to make `repoman -dx full` as happy as possible before committing.
Pkgcheck does even more checks than repoman. While it is good practice to make repoman as happy as possible, it is not necessary to fix *every* issue that pkgcheck reports. Because pkgcheck is *very* strict. That being said, pkgcheck is a very useful tool to perfect your ebuilds.
- #### Establish your package testing workflow
There are [make.conf flags](https://wiki.gentoo.org/wiki/Package_testing#make.conf_.26_test.conf) you might want to set to enable more QA checks.

View File

@@ -5,7 +5,6 @@
# The GURU Project Repository
[![pkgcheck](https://github.com/gentoo/guru/workflows/pkgcheck/badge.svg)](https://github.com/gentoo/guru/actions?query=workflow%3Apkgcheck)
[![repoman](https://github.com/gentoo/guru/workflows/repoman/badge.svg)](https://github.com/gentoo/guru/actions?query=workflow%3Arepoman)
[![contributions welcome](https://img.shields.io/badge/contributions-welcome-brightgreen.svg)](https://wiki.gentoo.org/wiki/Project:GURU/Information_for_Contributors)
[![chat on libera](https://img.shields.io/badge/chat-on%20libera-brightgreen.svg)](https://web.libera.chat/#gentoo-guru)

View File

@@ -1,31 +0,0 @@
#! /usr/bin/env bash
# Maintainer: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
# Maintainer: James Beddek <telans@posteo.de>
#
# This sets up repoman and runs the latest version
#
# TODO: Force repoman to output in colour
### Setup prerequisites
python3 -m pip install --upgrade pip
pip install lxml pyyaml
sudo groupadd -g 250 portage
sudo useradd -g portage -d /var/tmp/portage -s /bin/false -u 250 portage
### Sync the portage repository
git clone https://github.com/gentoo/portage.git
cd portage
# Get all versions, and read into array
mapfile -t RM_VERSIONS < <( git tag | grep portage | sort -uV )
# Select latests version (last element in array)
RM_VERS="${RM_VERSIONS[-1]}"
# Checkout this version
git checkout tags/${RM_VERS} -b ${RM_VERS}
cd ..
### Run repoman
python3 portage/repoman/bin/repoman -dx full