Ah, this explanation makes perfect sense. Thanks!<br><br><div class="gmail_quote">On Mon, Mar 14, 2011 at 2:12 PM, T3slider <span dir="ltr"><<a href="mailto:t3slider@gmail.com">t3slider@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Bumping the version number for every package on SBo would be the<br>
equivalent of doing `slackpkg clean-system` and recompiling each<br>
third-party application from <a href="http://slackbuilds.org" target="_blank">slackbuilds.org</a> -- which would be the<br>
standard advice for anyone having such troubles with multiple packages.<br>
Otherwise, applications that may be ABI-compatible with dependencies<br>
from Slackware 13.37 would need to maintain the same build number while<br>
others that would require a recompile would need a bump. Determining<br>
which ones would need this is too much effort in my opinion, especially<br>
when you get into issues like an application breaking not because it<br>
isn't ABI-compatible with Slackware packages, but because it isn't<br>
ABI-compatible with an SBo dependency that breaks with new Slackware.<br>
<br>
You can take your chances running old 13.1-compiled apps on 13.37 and<br>
recompile those that are broken, or clean-system and rebuild them all<br>
(`ls /var/log/packages/*_SBo` would get a list). Of course you would<br>
need to build them in the right order which would involve reading<br>
READMEs or using build queues. In the end, I don't think bumping<br>
versions has *any* benefit that I can see and it's certainly more work<br>
anyway.<br>
<div><div></div><div class="h5"><br>
On Mon, Mar 14, 2011 at 01:38:10PM -0400, Ben Mendis wrote:<br>
> Perhaps I misunderstood. I thought the proposal was to bump the build<br>
> number for SlackBuilds in the new 13.37 repository that would need to be<br>
> rebuilt after updating from 13.1 (as a convenience to sbopkg users). I had<br>
> assumed that the SlackBuilds in the 13.1 repository would stay the same<br>
> since no re-build was necessary.<br>
><br>
> Also, I realize that the build number can be specified at build-time, but<br>
> that doesn't provide any assistance to sbopkg users at all, they would<br>
> still need to manually add each package to the queue to be rebuilt.<br>
> (Furthermore, sbopkg seems to lack the ability to override the default<br>
> BUILD or TAG on a per-package basis, but that has nothing to do with SBo<br>
> itself.)<br>
><br>
> I can accept the argument that the build number reflects changes in the<br>
> SlackBuild itself, but there didn't seem to be any harm in making an<br>
> exception in this situation.<br>
><br>
> Oh well, it just means that users will need to do a bit more manual work<br>
> (and we'll probably find ourselves answering a lot of very similar<br>
> questions on LQ and ##slackware after people upgrade), but that really<br>
> nothing new.<br>
><br>
> Would it be acceptable for maintainers to submit a build bump if they<br>
> wanted to, or is there a hard "NO" on this issue?<br>
> Not that it even affects me since I don't currently maintain any packages<br>
> which would be affected.<br>
><br>
> --<br>
> - hba<br>
> _______________________________________________<br>
> SlackBuilds-users mailing list<br>
> <a href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.org</a><br>
> <a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
> Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
> FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br>
<br>
> _______________________________________________<br>
> SlackBuilds-users mailing list<br>
> <a href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.org</a><br>
> <a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
> Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
> FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br>
><br>
<br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.org</a><br>
<a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br>
<br>
</div></div></blockquote></div><br>