SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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!
do you edit in the main session and then just build in the chroot or VM?
That's what I do.
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).
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
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)
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 uninstall the new packages from the chroot after I'm done.
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).
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?
Quote:
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)
Good! I didn't know about 'slackpkg clean-system'. Will look into it.
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
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).
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.