sbotools 0.8 is now live. I’m writing significantly better perl than I used to, so much of the codebase has been modified, cleaned up, and tightened up. In fact, most of the changes with this release are visible only by reading the code. Additionally, the test suite is now much more comprehensive as I become more acquainted with test-driven development. Here’s a summary of what’s visible by someone not reading the code:
- A new option has been added to sboupgrade; instead of only being able to force-upgrade a single slackbuild, one can now specify -z to first upgrade any of a slackbuild’s requirements which sboupgrade is able to parse from its README. So, if you have two packages installed from slackbuilds.org, package A requiring package B, you can run something like “sboupgrade -fz packageA” and it will force both packages to be rebuilt.
- sboinstall/sboupgrade are now able to handle slackbuilds with special characters in their names, such as “libsigc++”; thanks to Cultist in ##slackware for pointing this out to me.
- Since the single-letter options are getting weird and potentially confusing, I added in long options which make a lot more sense alongside the previous single-letter options, so, for example, instead of saying “sboupgrade -f” you can say “sboupgrade –force” and so on.
- The man pages have been cleaned up and made more consistent (in my opinion of “consistent”).
- The requirement-parsing code has been slightly enhanced.
- A bug where sboinstall would exit silently for already-installed slackbuilds is fixed, so that it will now tell the user that slackbuild is already installed.
- A handful of minor and severely less-interesting bugs have been fixed.
I’m also currently working on a version for 14.0, which currently represents a different branch from this one since requirement-handling for 14 will be much, much nicer, and saner. Should it be a single unified version? I haven’t entirely decided yet, though I’ve been leaning towards “no”.
And, at the risk of feature-creep, I’m also seriously considering adding chroot ability for building 32-bit things on x86_64 systems, since, as time goes by and I become more and more used to working with multilib slack, I’ve learned that the only sane way (and in some cases the only way) to build certain slackbuilds is in a 32-bit chroot.