[Slackbuilds-users] [ANNOUNCE]: Slackware 13.37 rc1 and SBo

[slakmagik]

On 2011-03-14 (Mon) 13:49:51 [-0500], Robby Workman wrote:
> On Mon, 14 Mar 2011 13:38:10 -0400
> Ben Mendis <dragonwisard at gmail.com> wrote:
> 
> > 
> > Also, I realize that the build number can be specified at build-time,
> > but that doesn't provide any assistance to sbopkg users at all, they
> > would still need to manually add each package to the queue to be
> > rebuilt. (Furthermore, sbopkg seems to lack the ability to override
> > the default BUILD or TAG on a per-package basis, but that has nothing
> > to do with SBo itself.)
> > 
> 
> This is the first release that we've been using git during the change
> from previous to new, so the workflow is a bit different, and we can't
> do what we've always done, which is reset all of the BUILD numbers to
> "1" regardless.  It's never caused problems (that we're aware of) for
> sbopkg before, and I don't see why it should, and even if it does, I
> still don't think that would be a large enough issue to change what
> we do.  Besides, I'd be quite surprised if sbopkg didn't allow setting
> BUILD locally.
> 

Well... :) I'm surprised it doesn't allow it properly.

A way to change the build on a per package basis from the command line
is to use the 'per app options' syntax on the command line and use
standard vars (BUILD, etc.) like special vars (WITH_WHIZBANG_FEATURE,
etc.):

# sbopkg -i app:BUILD=build

However, doing the same for TAG fails because sbopkg uses an internal
variable. The following is *wrong* (because the user shouldn't use this
variable) but "works" (at least as far as building):

# sbopkg -i app:REPO_TAG=tag

The queuefiles don't-quite-work the same way:

app|BUILD=build REPO_TAG=tag

>From the menu interface, using the 'OPTIONS' item is the same - though,
if you didn't mind changing the SlackBuild, you'd could also use
'CUSTOM' to do it directly.

And, regardless, this isn't directly documented.

IOW, Ben, you should have reported this as a bug and there's work to do.
If there's anything you can do *without* sbopkg that you can't do *with*
sbopkg, it's at least theoretically a bug.

But, while possibly simple to fix (hope springs eternal), the general
issue is in a lot of areas of the code, some of it really squirrelly,
and a proper fix may have to wait until next time. As is (aside from one
small glitch whose tiny patch just needs to be tested a little more and
committed), sbopkg seems to be working (though changing BUILD and TAG is
awkward and inconsistent) and I wouldn't want to break anything right
now trying to smooth that out.

If this needs more discussion, shifting this part to sbopkg-users would
be best.

One last note: I don't know what you mean by "need to manually add each
package to the queue to be rebuilt". I keep a master queue of every SBo
package (or sub-queue of packages) on a given system (and one of local
stuff) and habitually rebuild everything at new Slackware/SBo releases
by reusing that (them). If you don't have such a queue then, from the
menu interface, there's 'Add/Add all installed packages to the queue',
'Sort/Sort items in build queue', and 'Save/Save the current build
queue' (though I'd just use $EDITOR for sorting in that case).