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

[Ben Mendis]

2011/3/14 Antonio Hernández Blas <hba.nihilismus at gmail.com>

> On Mon, Mar 14, 2011 at 7:41 AM,  <xgizzmo at slackbuilds.org> wrote:
> > That is correct the build number reflects the changes to the SlackBuild
> in
> > our case. But just for fun lets say you want to use the logic that this
> is
> > a new Slackware version and the build numbers need to be changed, then
> they
> > should all be reset to 1. In any case we don't dictate how the admin
> manage
> > their system but we do make provisions for the admin to change the build
> > number if they want to. For example BUILD="5" TAG="_SBo_13.37"
> ./Some.SlackBuild
> >
>
> Keeping BUILD the same helps to those one (like me) who still uses
> 13.0, so they just rsync its local port with SBo 13.1/13.37 and theres
> no need to worry (mostly) about changes between slackware version,
> BUILD and SBo ports at all... so i don´t see any need (at least for
> me) to use that "change-the-build-number-if-they-want" thing ;)
>

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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20110314/42dd08bc/attachment.html>