Piraty/mini guide for xbps-src

## mini guide for xbps-src
Setting up xbps-src

Docs
1: https://wiki.voidlinux.eu/Xbps-src
2: https://github.com/voidlinux/void-packages/blob/master/Manual.md
3: https://github.com/voidlinux/void-packages/blob/master/README.md

clone https://github.com/voidlinux/void-packages.git

$ xbps-install xtools
xtools provides "xi" (short for xbps-install.
It takes a local void-packages repo into account, so you can install your own built packages easily just by "xi <pkgname>")  (man xtools)

Now in void-packages
$ ./xbps-src binary-bootstrap (set up a build chroot env)
make a branch
- use an existing template to work on
- or make your own with "xnew <pkgname>"

Enable ccache (speeds up re-builds significantly!) and use multi-cpu
$ cat void-packages/etc/conf
XBPS_CCACHE=yes
XBPS_MAKEJOBS=4


$ ./xbps-src pkg <pkgname>
This should give you a first working build.
The package is configured, built and installed in a chroot and the .xbps file is derived from the installed files.
That one can be installed via "xi <pkgname>" when you are inside your void-packages-repo

Notes:
- chroot resides in masterdir
	- build runs in masterdir/builddir
	- files are installed into masterdir/destdir
- (packges reside in hostdir/binpkgs, but better use xi to install to system)
- after succesful build, the chroot is cleaned and dependencies are removed. use -C flag to preserve installed dependencies and the destdir
- upon a new call of ./xbps-src, it clean automatically, removing previously installed dependencies. So, if you re-run a lot and don't want to re-install the same depencencies everytime, use -C flag to skip cleaning
- if you mess up your master dir, use ./xbps-src zap and run ./xbps-src binary-bootstrap again
- if you already have an .xbps-file in hostdir/binpkgs with the same version+revision as the template you are building, it will not overwrite this file upon new build. use ./xbps-src -f pkg <pkgname> to force overwrite it
- keep your void-packages repo in sync with upstream, otherwise you end up building outdated templates (use sth like git pull --rebase upstream master)
	Setting up xbps-src

	Docs
	1: https://wiki.voidlinux.eu/Xbps-src
	2: https://github.com/voidlinux/void-packages/blob/master/Manual.md
	3: https://github.com/voidlinux/void-packages/blob/master/README.md

	clone https://github.com/voidlinux/void-packages.git

	$ xbps-install xtools
	xtools provides "xi" (short for xbps-install.
	It takes a local void-packages repo into account, so you can install your own built packages easily just by "xi <pkgname>") (man xtools)

	Now in void-packages
	$ ./xbps-src binary-bootstrap (set up a build chroot env)
	make a branch
	- use an existing template to work on
	- or make your own with "xnew <pkgname>"

	Enable ccache (speeds up re-builds significantly!) and use multi-cpu
	$ cat void-packages/etc/conf
	XBPS_CCACHE=yes
	XBPS_MAKEJOBS=4


	$ ./xbps-src pkg <pkgname>
	This should give you a first working build.
	The package is configured, built and installed in a chroot and the .xbps file is derived from the installed files.
	That one can be installed via "xi <pkgname>" when you are inside your void-packages-repo

	Notes:
	- chroot resides in masterdir
	- build runs in masterdir/builddir
	- files are installed into masterdir/destdir
	- (packges reside in hostdir/binpkgs, but better use xi to install to system)
	- after succesful build, the chroot is cleaned and dependencies are removed. use -C flag to preserve installed dependencies and the destdir
	- upon a new call of ./xbps-src, it clean automatically, removing previously installed dependencies. So, if you re-run a lot and don't want to re-install the same depencencies everytime, use -C flag to skip cleaning
	- if you mess up your master dir, use ./xbps-src zap and run ./xbps-src binary-bootstrap again
	- if you already have an .xbps-file in hostdir/binpkgs with the same version+revision as the template you are building, it will not overwrite this file upon new build. use ./xbps-src -f pkg <pkgname> to force overwrite it
	- keep your void-packages repo in sync with upstream, otherwise you end up building outdated templates (use sth like git pull --rebase upstream master)