Skip to content
GitLab
Open
Created by steadfasterX@steadfasterX😁Guest

arch linux: packaging the easy-installer (AUR)

Description

package the easy-installer for the Arch Linux User Repository (AUR): https://aur.archlinux.org/packages/easy-installer/

as discussed with @arnauvp it would be great having the easy-installer in the AUR as it is already - just maintained by the project.

Requirements

Build steps

when a new easy-installer release comes out:

  1. change pkgver in PKGBUILD - the version should always reflect your release (i.e "tag") and should not contain words like "beta"
  2. change pkgrel if the change is bc of the package itself (so easy-installer sources haven't changed)
  3. ensure all other arch-pkg files which had required a change get added into the commit
  4. ensure all md5sums are correctly set in md5sums
  5. follow Publishing_new_package_content: https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Publishing_new_package_content

CI process

What I do not know is your OS used by your CI pipeline as the tool makepkg is an Arch tool (included within pacman) but needed to create the important .SRCINFO file.

Editing that file manually might be possible while it's not recommended. Using a docker image could be an option and a starting point could be that one here - maybe. Using docker would also have another advantage: the pkg build process could be fully tested before releasing a new version to the AUR.

so the process would be:

  1. ensure any needed adjustments (e.g. removing/adding patches) are done in the main repo
  2. ensure md5sums are correct in the main repo (i.e. the gitlab easy-installer one)
  3. make the AUR - SSH key available in the docker image (guess you know better then me how) and ensure it will be used for git push (i.e. ~/.ssh/config)
  4. optional while recommended: make the GPG signing key available in the docker image (guess you know better then me how) and ensure it will be used for git commit (i.e. ~/.gitconfig)
  5. Use Docker to create the .SRCINFO, test the package, push the changes. I wrote the following DOCKERFILE but haven't tested it yet (I am not a docker friend) but it explains at least what needs to be done. I have added comments for every step so it is better understandable:
(DOCKERFILE)

FROM archlinuxrolling/pacman
FROM archlinux/base
RUN pacman -Syu --noconfirm && yes | pacman -Scc && rm -fr /var/lib/pacman/sync/*

# requirements for packaging
RUN pacman -S --noconfirm git

FROM scratch
COPY --from=1 / /
ENV LANG=en_US.UTF-8

# clone the AUR repo
RUN git clone ssh://aur@aur.archlinux.org/easy-installer.git

# clone the /e/ repo
# an automated replacement for <TAGGED-RELEASE> with the correct tag is needed here:
RUN git clone ssh://git@gitlab.e.foundation:2222/e/tools/easy-installer.git -b <TAGGED-RELEASE> easy-installer_src

# copy the package files from the /e/ clone into the AUR clone
RUN cp -a easy-installer_src/pkg/arch/* easy-installer/
RUN cp -a easy-installer_src/pkg/arch/.* easy-installer/

# build to ensure we do not release a broken pkg:
RUN cd easy-installer/ && makepkg -sifc --noconfirm

# create .SRCINFO , commit and push to the AUR:
# the arg: -m "$(grep pkgver= PKGBUILD | cut -d = -f 2) - $(date +%s)" 
# will grab the pkgver version and adds the current unix timestamp (e.g. "0.11.2 - 1609330519")
# again just an example..
# also if you want to SIGN your commit (recommended) the git commit must be adapted accordingly
# and ofc you need to have access to your GPG key from within this container
RUN cd easy-installer/ && \
    makepkg --printsrcinfo > .SRCINFO && \
    git add .SRCINFO && \
    git commit -m "$(grep pkgver= PKGBUILD | cut -d = -f 2) - $(date +%s)" && \
    git push

again I am not a docker pro and the above is untested (e.g. I do not know if the second RUN cd easy-installer/ is needed actually or if it stays in that dir so on the next RUN it is still in there?!). Anyways it should give you an idea how it might should work. feel free to ask ;)

The other option which MIGHT work - if you are using a DEB based OS could be https://github.com/devkitPro/pacman . Even though I do not know if that works at all testing the full pkg build process would not be possible then (e.g. the dependencies in Arch are different then in Debian etc) so it should be used as a last resort only (imho).

Edited by steadfasterX