[Dev] Fauno's workflow
Luke T. Shumaker
lukeshu at sbcglobal.net
Fri Nov 30 06:45:22 GMT 2012
Fauno put this file in /doc/ in libretools, but I felt the best way to
discuss it was an email
> ## 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
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,
* 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)
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.
> * 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
> 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
`librechroot -c` now uses chcleanup to clean the chroot.
> * Building many packages in a row without recreating a chroot for every one of
libremakepkg did not recreate the chroot automatically before, and
> * 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.
~ Luke Shumaker
More information about the Dev