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@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@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@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/