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

[T3slider]

Bumping the version number for every package on SBo would be the
equivalent of doing `slackpkg clean-system` and recompiling each
third-party application from slackbuilds.org -- which would be the
standard advice for anyone having such troubles with multiple packages.
Otherwise, applications that may be ABI-compatible with dependencies
from Slackware 13.37 would need to maintain the same build number while
others that would require a recompile would need a bump. Determining
which ones would need this is too much effort in my opinion, especially
when you get into issues like an application breaking not because it
isn't ABI-compatible with Slackware packages, but because it isn't
ABI-compatible with an SBo dependency that breaks with new Slackware.

You can take your chances running old 13.1-compiled apps on 13.37 and
recompile those that are broken, or clean-system and rebuild them all
(`ls /var/log/packages/*_SBo` would get a list). Of course you would
need to build them in the right order which would involve reading
READMEs or using build queues. In the end, I don't think bumping
versions has *any* benefit that I can see and it's certainly more work
anyway.

On Mon, Mar 14, 2011 at 01:38:10PM -0400, Ben Mendis 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.
> 
>    Oh well, it just means that users will need to do a bit more manual work
>    (and we'll probably find ourselves answering a lot of very similar
>    questions on LQ and ##slackware after people upgrade), but that really
>    nothing new.
> 
>    Would it be acceptable for maintainers to submit a build bump if they
>    wanted to, or is there a hard "NO" on this issue?
>    Not that it even affects me since I don't currently maintain any packages
>    which would be affected.
> 
>      --
>      - hba
>      _______________________________________________
>      SlackBuilds-users mailing list
>      SlackBuilds-users at slackbuilds.org
>      http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>      Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>      FAQ - http://slackbuilds.org/faq/

> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>