## general

- `pkgcheck scan` after writing ebuilds
- test in a real emerge session so that network isolation is properly
  enforced (this isn't enforced in `ebuild` command)
- for extra distfiles, use `mirror://jacksonchen666/` instead of manually
  specifying a URL of a specific host

## ebuild migration to GURU

assumptions:
- portage will pick ebuild from repo with newest version
- portage will news notify, assuming i do the thing correctly
    - only once, after it's been read
- (news item) people using my repo (following my setup instructions) already have git
  and eselect-repository, allowing them to effortlessly enable guru repo

1. add ebuild atom into news
2. copy ebuild to guru
3. change metadata:
    - email (gentoo specific email, match bugzilla)
    - name (full name)
4. `pkgcheck scan .` and fix QA complaints when possible
5. `pkgdev commit`
6. when pushing, use `pkgdev push`
7. push this repo's news changes
8. wait for changes to be merged from dev to master branch
9. after part of master branch in GURU, version the atom in the news thing
   here
10. and remove it from this repo

## go stuff

- `inherit go-module`
    - `src_compile` required
    - `src_install` required
    - <https://wiki.gentoo.org/wiki/Writing_go_Ebuilds#Compiling_and_installing>
- licenses: `go-license report .`
- when defining `src_unpack`, call `go-module_src_unpack`
    - this sets up all the verbose logging from go compiling stuff. go
      defaults to being silent, which is unexpected for gentoo users, who
      get very verbose compiling process on basically everything
- for repos without a vendor/deps tarball, make own, see below

### making go vendor/deps tarballs

1. comment out any vendor/deps `SRC_URI`s and related stuff
2. run `ebuild <ebuild filename> manifest unpack`
3. go to the work directory
4. go inside the directory with source code within the workdir (or `$S`)
5. get vendor/deps stuff
    - vendor (preferred): `go mod vendor`
    - deps (do note that it's necessary if necessary): `GOMODCACHE="${PWD}"/go-mod go mod download -modcacherw -x`
6. `cd ..` into the workdir
7. run one of the following commands depending on whether it's a vendor or
   deps

   ```
   XZ_OPT='-T0 -9' tar -acf ${P}-vendor.tar.xz ${P}/vendor/
   XZ_OPT='-T0 -9' tar -acf ${P}-deps.tar.xz ${P}/go-mod/
   ```
8. rsync to https://files.jacksonchen666.com/gentoo/

## python stuff

`pkgcheck scan` doesn't seem to have warnings or anything? and i'm not sure
where to look for general python ebuild QA
(https://projects.gentoo.org/python/guide/ doesn't exactly answer all my
questions), so i'm kinda doing this based on random stuff

- apply `[${PYTHON_USEDEP}]` on python dependencies,
  `[${PYTHON_SINGLE_USEDEP}]` for python dependencies on ebuilds that use
  `python-single-r1` or single implementation pythons
    - if trying an ebuild results in something with
      `%PYTHON_USEDEP-NEEDS-TO-BE-USED-IN-PYTHON_GEN_COND_DEP%`, then wrap
      the dependencies with those use flags with `$(python_gen_cond_dep '')`
      with the dependencies in the single quotes
- put `${PYTHON_DEPS}` into `RDEPEND` and `BDEPEND`
- prefer multi-impl python, but make sure to test with multiple
  implementations and switch between them

## rust stuff

- for new ebuilds, `pycargoebuild`
    - `--features` if there are features worth including in USE flags
- on every new version of rust-based ebuilds, use `pycargoebuild --input
  path/to/current-ebuild path/to/project/source/` to update `CRATES` and
  `LICENSE` without having to diff things manually
    - the project's source code must be updated first

## plover plugins

- copy `skel.ebuild`
- follow `dev-python/`'s rule of matching PyPI name, including using dashes
  instead of underscores
- check for dependencies in `setup.cfg`
- (required) install and test plugin
- do `metadata.xml` (check `pkgcheck scan .` i guess)
- tests as applicable

about `skel.ebuild`:
- assumes `setuptools` as build system
- fetches with `pypi.eclass`