<br><br><div class="gmail_quote">2011/3/14 Antonio Hernández Blas <span dir="ltr"><<a href="mailto:hba.nihilismus@gmail.com">hba.nihilismus@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Mon, Mar 14, 2011 at 7:41 AM,  <<a href="mailto:xgizzmo@slackbuilds.org">xgizzmo@slackbuilds.org</a>> wrote:<br>
> That is correct the build number reflects the changes to the SlackBuild in<br>
> our case. But just for fun lets say you want to use the logic that this is<br>
> a new Slackware version and the build numbers need to be changed, then they<br>
> should all be reset to 1. In any case we don't dictate how the admin manage<br>
> their system but we do make provisions for the admin to change the build<br>
> number if they want to. For example BUILD="5" TAG="_SBo_13.37" ./Some.SlackBuild<br>
><br>
<br>
</div>Keeping BUILD the same helps to those one (like me) who still uses<br>
13.0, so they just rsync its local port with SBo 13.1/13.37 and theres<br>
no need to worry (mostly) about changes between slackware version,<br>
BUILD and SBo ports at all... so i don´t see any need (at least for<br>
me) to use that "change-the-build-number-if-they-want" thing ;)<br></blockquote><div><br>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.  <br>
<br>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.)<br>
<br>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. <br><br>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. <br>
<br>Would it be acceptable for maintainers to submit a build bump if they 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 which would be affected. <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888"><br>
--<br>
- hba<br>
</font><div><div></div><div class="h5">_______________________________________________<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>