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

[Robby Workman]

On Mon, 14 Mar 2011 13:38:10 -0400
Ben Mendis <dragonwisard at gmail.com> wrote:

> Perhaps I misunderstood. I thought the proposal was to bump the build
> number for SlackBuilds in the new 13.37 repository that would need to
> be rebuilt after updating from 13.1 (as a convenience to sbopkg
> users). I had assumed that the SlackBuilds in the 13.1 repository
> would stay the same since no re-build was necessary.
> 
> 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.)
> 
> I can accept the argument that the build number reflects changes in
> the SlackBuild itself, but there didn't seem to be any harm in making
> an exception in this situation.


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.


> Would it be acceptable for maintainers to submit a build bump if they
> wanted to, or is there a hard "NO" on this issue?


No, that's a timesink that we can't afford at this point.

-RW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20110314/79891e35/attachment.asc>