Slackware power developers' environment
 

Hi Eric, Robby and other power developers,

I would love to know how you organize your environment to develop and test and ensure integrity of Slackware packages: VMs, containers, chroot, isolated build machines, signatures, distcc, automation, ... etc.

As I think it may be of interest for other fellow slackers, I ask here ...but let me know if you think it is too confidential, doesn't deserve an answer, or if you have already answered similar question elsewhere

Many thanks in advance

Phil

PS. I don't ask our BDFL because there is an aura of mystery around the core Slackware developement. I guess the process is known only to initiates of the 1st circle. Let's ask the initiates first ;)

I make sure my SBo submissions build in a -stable chroot.

Alien Bob uses VMs.
http://www.linuxquestions.org/questi...4/#post5477329

I use VMs :)

Thanks for your answers. Practically, do you do all the work (writing the slackbuild, writing code if needed), in the chroot or VM? with a GUI? or do you edit in the main session and then just build in the chroot or VM?

In the case of the VM, how do you exchange information (slackbuild, source code, resulting package) between the main session and the VM? (SMB/samba? NFS? SSH/scp?, mounting an image in the VM and then back in the main session?, something else?)

What is your typical workflow? - I am looking for good ideas and good practices!

TIA

Phil

That's what I do.

For exchanging files with the VM, I'd think you'd just use VirtualBox's folder-sharing feature.

Not a "power developer" but for my SlackBuilds, I create a Qemu image and install Slackware on it. Then I take a snapshot of it.

I work locally in Emacs.

I scp my build scripts to the qemu snapshot, build, install, test.

Rinse and repeat, creating fresh snapshots as needed.

I manage my build scripts with git, but submit updates and changes via the submission for on SBo.

Do you take any specific step to ensure the integrity of the chroot?

I mean, to test a slackbuild in a clean, stable environment, do you first copy the full chroot from a clean version? I guess that after building several slackbuilds, the chroot starts to diverge from a pristine install...

I am concerned by this dev environment integrity issue since I understand that the Slackware approach is "build as root" (so any slackbuild can potentially modify the dev environment itself).

I used to build and test first on my main desktop. After it confirms to build and all the functionality works well, then i transferred it to a clean VM (because i have lots of third party packages from SBo and from my own projects) and build it there. It may take several attempts to find the whole deps but i use sbopkg for managing dependencies available in SBo. I simply use scp to transfer since SlackBuild scripts and all related files are very small (exclude the source).

The VM itself will be cleaned out by simply using slackpkg clean-system and in most cases it simply revert to the original conditions (exclude new users/groups created or new config leftovers which should be harmless but needs to be removed manually)

Interesting. The snapshot thing adresses my concern about the build environment integrity.

For snapshots, do you make a copy of the Slackware image file, or do you use the qemu copy-on-write support?

I uninstall the new packages from the chroot after I'm done.

When you are done building the new package on the VM, do you install and test it in the VM? or do you scp it back and install/test it in your main desktop?

By the way, what VM do you use? Qemu, virtualbox, something else?

Good! I didn't know about 'slackpkg clean-system'. Will look into it.

i test both on main desktop and VM
i use VBox (SBo) and VMWare (MSB and CSB), but i do have qemu as well :)

For snapshots, I use the Qemu snapshot function. I don't know if that's the same as copy-on-write.

Specifically:

Then I use the snap*img file as my new VM; all changes are applied to it rather than the base image.

For the perfect easy-clean build experience, combine a whole-system chroot with overlayfs.

And now everything the SlackBuild did is under /tmp/changes, and / is completely unchanged.

You're right, but for Slackware proper (not external repo's) this doesn't really matter because what ever packages are being built for Slackware end up in Slackware, or if a version is tried and isn't going to be used, it's simply upgradepkg'd back to the original one (and if the Slackbuild has some hacks that install stuff to the file system rather than the package's directory, then those things can be cleaned up manually, or as I do on ARM, I just rebuild the original version of a package and increment the build number).

If I were building binary packages to distribute for Slackware then the best practice is:
1. Install a full clean Slackware (or if you know that your packages don't need X for example, don't install it); or restore from your previous clean snapshot.
2. If it's a stable release, upgradepkg the patches/ directory.
3. If you're using a VM, take a snapshot that you can restore to. Why reinstall again for the next build if you can just restore to a clean snapshot?
3. Build and install any dependencies (that are not within Slackware)
4. Build and install the package you want.

The final package will include the chain of dependencies, or in the case of Slackbuilds.org you list which dependencies are required up front so people can fetch and build those themselves.

There used to be a site that served precompiled Slackware packages, but the quality was very poor and the packages had no quality control. One of the issues was that it seemed as if people building the packages would just build stuff on their system and put them out; but their system had many other packages that the new package found and linked against. These packages were not mentioned anywhere and as a consequence their binary package would fail to run.

Occasionally if I see someone struggling with something on Slackware ARM, I'll try building it on one of my spare systems that won't be involved in producing the main tree, and that system will never build another ARM package for the tree until it's reinstalled because I don't want anything to pollute packages in the main tree, otherwise I have a big problem to deal with.