[Dev] Fauno's workflow

[Luke T. Shumaker]

Fauno put this file in /doc/ in libretools, but I felt the best way to
discuss it was an email

Fauno wrote:
> ## fauno's way
> 
> During packaging, I don't usually restart a build from scratch if I have to
> make changes to the PKGBUILD. I use a lot of commenting out commands already
> ran, `makepkg -R`, etc. When I used `libremakepkg` I ended up using a lot more
> `librechroot` and working from inside the unconfigured chroot, because
> `makechrootpkg` (the underlying technology for `libremakepkg`) tries to be too
> smart.

I'm not sure that's a "safe" way to build packages. I might do that
while getting a package to build, but I always build from scratch at
the end. "ccache" makes this bearable.

Also, libremakepkg no longer uses makechrootpkg, and is *very*
transparent and doesn't try to be too smart.

 * Copies the PKGBUILD and sources in (ok, some clever things happen
   to copy the sources)
 * Runs checks on the PKGBUILD (currently pkgbuild-check-nonfree,
   eventually librenamcap)
 * Runs "makepkg -o"
 * Runs checks on the source directory
 * Runs "makepkg -e" with networking dissabled in the chroot
 * Copies the resulting packages to SRCDEST.

> When I started writing `treepkg` I found that mounting what I need directly on
> the chroot and working from inside it was much more comfortable and simple than
> having a makepkg wrapper doing funny stuff (for instance, mangling makepkg.conf
> and breaking everything.)

There is still some mangling of pacman.conf that I don't understand
(maybe it is important; I'm affraid to remove code I don't understand)
https://labs.parabola.nu/issues/256

However, all that happens to makepkg.conf is it sets PKGDEST and SRCDEST.

> This is how the chroot is configured:
> 
> * Create the same user (with same uid) on the chroot that the one I use regularly.
> 
> * Give it password-less sudo on the chroot.
> 
> * Bind mount /home to /chroot/home, where I have the abslibre-mips64el clone.

I'm not sure that's a good idea; maybe it works for you, but
 * A lot of tools look at configuration in $HOME; a chroot means it is
   a fresh directory... unless you bind mount /home.
 * A chroot also protects you from a misbehaving build script messing
   with your $HOME.

> * Bind mount /var/cache/pacman/pkg to /chroot/var/cache/pacman/pkg
> * Put these on system's fstab so I don't have to do it everytime

archroot (librechroot's backend) bind mounts that for you so you don't have to
have it in fstab or do it manually.

> * Configure makepkg.conf to PKGDEST=CacheDir and SRCDEST to something on my home.
> 
> Workflow:
> 
> * Enter the chroot with `systemd-nspawn -D/chroot` and `su - fauno`.
> 
> * From another shell (I use tmux) edit the abslibre or search for updates with
>   `git log --no-merges --numstat`.
> 
> * Pick a package and run `treepkg` from its dir on the chroot, or retake
>   a build with `treepkg /tmp/package-treepkg-xxxx`. (Refer to doc/treepkg
>   here).
> 
> What this allows:
> 
> * Not having to worry about the state of the chroot. `chcleanup` removes and
>   adds packages in a smart way so shared dependencies stay and others move
>   along (think of installing and removing qt for a complete kde
>   rebuild).

`librechroot -c` now uses chcleanup to clean the chroot.

> * Building many packages in a row without recreating a chroot for every one of
>   them.

libremakepkg did not recreate the chroot automatically before, and
can't now.

> * Knowing that any change you made to the chroot stays as you want (no one
>   touches your makepkg.conf)

For someone who doesn't work from inside the chroot, only setting
PKGDEST and SRCDEST seems to be a good balance between "don't mess
with my stuff" and "just work".

> * Hability to run regular commands, not through a chroot wrapper. I can `cd` to
>   a dir and use `makepkg -whatever` on it and nothing breaks.
> 
> * No extra code spent on wrappers.

Again, I'm working to make libremakepkg provide more checks than
simply working in a clean chroot does.

Happy hacking,
~ Luke Shumaker