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

Ben Mendis dragonwisard at gmail.com
Wed Mar 16 01:57:09 UTC 2011


On Tue, Mar 15, 2011 at 5:04 PM, slakmagik <slakmagik at gmail.com> wrote:

> On 2011-03-14 (Mon) 23:03:34 [-0500], Robby Workman wrote:
> > On Mon, 14 Mar 2011 23:49:08 -0400
> > Eric Pratt <eric.b.pratt at gmail.com> wrote:
> >
> > > On Mon, Mar 14, 2011 at 10:55 PM, slakmagik <slakmagik at gmail.com>
> > > wrote:
> > > >
> > > > If there's anything you can do *without* sbopkg that you can't do
> > > > *with* sbopkg, it's at least theoretically a bug.
> > > >
> > >
> > > I knew it was a bug when I couldn't make a pot pie with sbopkg.  I
> > > just KNEW it!
> >
> >
> > While we're fixing these egregious oversights, someone should figure
> > out how to make it bring me a beer.  ;-)
> >
>
> Oops :) - scope error. I mean "anything related to building SBo
> packages". Though, actually, then it should still probably bring pot
> pies and beer. ;)
>
> Oh, and to Ben, I have a question - I was originally thinking about
> abstract consistency for per app settings but is there a use case where
> you'd *want* to set the BUILD of all packages to the same number or the
> TAG of a set of packages to different values? While not the most
> consistent (but, after all, they're doing different things),
>
> # sbopkg -i foo:BUILD=build # per app
> # TAG=tag sbopkg -i foo     # all apps
>
> should cover most needs.
>

I didn't realize it was possible to use the "foo:BUILD=build" syntax to set
per-package build numbers. Off the top of my head, I can't think of any
reason to mangle either value, but I'm sure someone could find a clever way
to abuse either or both.

Also, I had always assumed that the BUILD number represented the package
build and not the SlackBuild revision. Eg, if Pat were to rebuild a package
against a new library using the same SlackBuild, wouldn't he bump the BUILD
of that package in the tree? But I guess SBo is doing it differently since
they host SlackBuilds and not packages. (And the issue of complex dependency
chains makes perfect sense as well.)

> _______________________________________________
> 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/20110315/42f57463/attachment.html>


More information about the SlackBuilds-users mailing list