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

[Ben Mendis]

Ah, this explanation makes perfect sense. Thanks!

On Mon, Mar 14, 2011 at 2:12 PM, T3slider <t3slider at gmail.com> wrote:

> 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/
> >
>
> _______________________________________________
> 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/9fc3758b/attachment.html>