Skip to content

Instantly share code, notes, and snippets.

@vodik
Last active August 29, 2015 14:20
Show Gist options
  • Save vodik/246f2c4320826dd1edfa to your computer and use it in GitHub Desktop.
Save vodik/246f2c4320826dd1edfa to your computer and use it in GitHub Desktop.
opinionated repo [draft]

Opinionated approach to managing foreign packages

This is my opinionated approach to managing foreign packages in Arch Linux. In my humble opinion,

  1. Manually review PKGBUILDs from the internet to vet for correctness.
  2. Build in a clean chroot to ensure dependancies are correct.
  3. Make it easy to build stuff when dependancies are also foriegn.
  4. Easily share packages across multiple machines
  5. Cross compile to support i686 as well.
  6. Rebuild any past version.

Especially if you plan on deploying the same set of packages with multiple machines or other people.

Getting started

For the sake of this article, I'm going to create a personal repository called vodik. I want to aim to be able to add something like the following to your pacman.conf and be able to fetch all your personal packages through pacman across your network.

[vodik]
Server = http://localhost/repo/$arch

Another assumption I'm going to make is that you're compiling for x86. If you're on a different architecture, change the instructions as desired or just drop the archtecture bit all together. I only specify the architecture because I'll cover cross compiling to provide packages and a repository for both architectures together.

Setting Up a Repository

Why is this the first step? The tricky thing with this setup is that our build system is also going to depend on our repository. This way when building packages with dependancies that also need to be compiled, those dependancies can just be pulled from our personal repo.

This means that we have to create an initial empty repository to bootstrap the whole process.

$ touch repo/x64_64/vodik.db

Next is the hosting. I personally use nginx. Setup nginx now.

server {
    listen 80;
    server_name vodik;

    location /repo {
        autoindex on;
        alias /home/simon/vodik/repo
    }
}

We can now test that the repo works by adding it to our pacman.conf and seeing if it works.

Managing PKGBUILDs and Sources

I am not a fan of the very automatic tools because, well, they're too automatic. They make a certain set of compromisses and I'm interested making different choices.

First we need to setup a location to store our PKGBUILD files. I think its important to keep them around and tracked in a git repository for auditing.

Keeping the sources around means its easy to rebuild. Rebuild old versions with different config flags, even if the original source is offline.

When dealing with VCS's, rebuilds become incremental instead of a full clone each time we build that package.

Building Packages

I really recommend using the devtools package. This enables us to build in a clean chroot, which will catch problems like missing dependancies and prevent unintented or unwanted linking to other packages on your current system. This isn't the biggest problem when building packages soely for personal use on one machine, but it prevent potential problems when sharing packages with other machines.

First we need to write a custom

Storing resulting packages

I stash all resulting packages into another folder. This makes it a lot easier to compile the resulting repository.

Building a repository

While pacman provides the repo-add/repo-remove commands, I wrote my own tool for this step: repose. My tool is significantly smarter and can automatically update and build repositries directly.

Checking for updates with cower

If you've packaged stuff from AUR, cower can still be an invaluable too for alerting you that updates are available. Add the following to your cower config file:

IgnoreRepo = vodik

This causes cower -u to pretend your repository doesn't exist, which means that it'll treat installed packages from that repository as if they're foreign. Note that you'll only get information about packages you've installed on your system.

Tooling:

  • devtools
  • repose
  • cower
  • nginx

Repo layout:

├── build
│   ├── i686
│   └── x86_64
├── pkgbuilds
├── pkgdest
├── repo
│   ├── i686
│   └── x86_64
└── srcdest

Use btrfs:

  • Setup your build chroots:

    • Cross compile for i686
    • Choose what you're targetting: standard repos, testing repos, etc. Don't mix. Otherwise you need a seperate [foo-testing] repo
  • Maintain pkgbuilds under pkgbuilds

  • Use makepkg.conf

PACKAGER="You <youremail@example.com"
SRCDEST="<buildroot>/srcdest/"
PKGDEST="<buildroot>/pkgdest/"
  • Build using devtools for clean builds whenever you can:
makechrootpkg -cr ./build/x86_64

Packages targetting -any only need to be built once. If there's interest in provided a i686 version, rerun the makechrootpkg command in the other build environment.

  • Repose to build the repository
#!/bin/bash

source ~/.makepkg.conf
for arch in i686 x86_64; do
    repose -vJf -m $arch -p "$PKGDEST" -r ~/repo/$arch sangoma --reflink
done

Siging:

  • signing packages
  • siging repositories
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment