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

4 members found this post helpful.

I use VMs

3 members found this post helpful.

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

1 members found this post helpful.

That's what I do.

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

1 members found this post helpful.

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.

4 members found this post helpful.

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)

3 members found this post helpful.

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.

1 members found this post helpful.

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

2 members found this post helpful.

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.

4 members found this post helpful.

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.

12 members found this post helpful.

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.

9 members found this post helpful.