Sbopkg Popularity
 

Hello All!

I have been using the Sbopkg tool for a while, with great success, and began to wonder why this simple and easy to use tool is not more popular and given more attention among the Slackware community.

It is a straightforward add-on that merely automates the downloading and installing slackbuilds and its sources.

However, I only found out about it in a round-about way, and it saves me hours of needless work downloading and organizing my slackbuilds.

No, I do not represent Sbopkg...I'm just very curious why an application such as this is not mainstream.

Thanks!
Murdock

Because it is still in a testing phase, as stated in its homepage

Hello Didier,

Gotcha...but that's kind of my point exactly. Why haven't people pushed more to get it mainstream and out of testing phase?

It is basically a slackpkg tool for slackbuilds.

Murdock

It reminds me a bit of a ports system.

It does seems a great tool, but it doesn't, as far as I can tell, determine that you have to meet any dependencies before trying to build and install any given package. For that reason, I'm not sure I won't still be surfing through slackbuilds repos via browser then downloading everything I need so that I can build and install everything in the proper order--when such a thing matters, of course.

Of the Slackbuilds.org scripts I tried, many were bad. Almost every time I
contacted them I got a really defensive, bad attitude reply. So since I
wouldn't use slackbuilds.org scripts, I wouldn't use sbopkg.

Third-party package managers never have gone over well in Slack.

@ Bruce Hill
To bad you have an so bad experience with slackbuilds.org
I found there builds to be the best there is for slackware and i maintain some myself so i may not be the right one to share my opinion.
And the really defensive, bad attitude reply from SBo, doesn't sound right if you ask me.
I use sbopkg allot and it's a great tool.

@robert3242
You don't need to browse the website since you can read the README files for the SlackBuilds.
And there is an build queue that you can sort for build order.

So i like to thank Chess for sbopkg and the SBo team and maintainers for there job.

But if there are negative feelings about SBo then it's good that it comes out so SBo can improve and get even better since nothing is perfect.

sbopkg is actually already a pretty popular tool, but it is a relatively new tool. There has been at least one online article featuring it. It probably will never be "mainstream" in the sense that it gets included with Slackware, however. This is because its use is for facilitating the creating of third party packages.

Which SlackBuilds were bad, and who is them (the SlackBuild maintainers or the SBo team)?

Since the SlackBuilds are submitted from a variety of people in the community, it is true that they can vary in quality coming in. However, the SBo team reviews and tests all the submitted scripts before accepting them. It is expected that submitted scripts follow certain guidelines and a template.

In addition it should be noted that the members of the SBo team include some major Slackware contributors such as Robby Workman and Eric Hameleers. These guys know what they are doing. If I am not mistaken Eric rewrote the official Slackware SlackBuilds to allow them to work for multiple architectures. I find it very hard to believe that many of the SlackBuilds are bad. Many many of the SlackBuilds eventually lead to new software included in Slackware.

Perhaps you did not use them correctly. I don't remember seeing any bug reports by you on the SBo mailing list, but please refresh my memory if I am mistaken. I am not trying to attack you, but your statement about the quality of SBo needs clarification.

I have 100+ packages installed that were created using SBo scripts and I have had no problems with any of them. Usually the issues people have with the resultant software packages are actually upstream issues that can only be fixed upstream (and not with simple patches at SBo).

Hi Bruce,

I maintain a handful of those scripts, hope mine was not one of the bad ones :-).

Andrew

I've used several Slackbuilds, and none of them were bad. I even threw VLC from 12.2 on -current a few months ago and on 13 today, and it was fine. (Yes, I'm impatient and a bit lazy.) I guess I'm a candidate for trying out sbopkg, but to be honest I'm doing okay without it, and that's maybe why it isn't so popular.

I use both slackbuilds and sbopkg regularly and rarely, if ever, had any problems. To me they are essential for system administration. To make things perfect you would need an official third party site with all possible slackbuilds on it.

samac

Never had any problems with SlackBuilds, never had any problem with sbopkg.
The only problems I've had with Slackware in general have been self-induced: NRTFM or NRTFI.

sbopkg saved me lotta time and queues are the materialization of slack! :)
with time (as slackbuilds.org gets more populated) it increases usefulness.
a sure thumb up!

I hate to point out the fairly obvious here, but: Sbopkg is not really a package manager. Sbopkg only compiles and builds the package, the actual installation is handled just normally by a call to slackware pkgtools and friends.

Perhaps a fine distinction to be made, but one correct anyway. SBopkg does automate/presents things a little bit more userfriendly than "source *.info && wget -c $DOWNLOAD && sh *.SlackBuild && installpkg ....... " (although I think sbopkg calls upgradepkg rather then installpkg.

Just out of curiosity, which builds did actually fail to build?

-M.

I haven't had any problems with slackbuilds.org; I'm impressed with the quality of the site. For me the build scripts have always functioned properly.

I have been using slackbuilds.org for quite a few releases now, and have never had a problem. I already have nearly 50 slackware.org-built packages on 13.0. This is the first release for which I have used sbopkg extensively, and I find it very convenient and have had no problems with it.

I'm curious which builds proved problematic?

Brian

The last Slackbuilds.org script that didn't build properly was Amaya.
Among other problems, the SBo script was written to install Amaya into
/opt, which is not according to convention, and Amaya does not do that
by default. I'd built Amaya previously, but v11.2 had changed so much
that I wanted to see how someone else did it. Couldn't with SBo.

The OP asked "why this tool is not more popular", and that's my answer.
A lot of guys liked LinuxPackages.net, also; I never did. I'm entitled
to my opinion just as much as you are to yours.

When I started with slackware I heard 1st of all something about linuxpackages and for a noob it's the easiest way to install something. Then I discovered slacky.eu and these both adresses were for a long time my only source for new apps except some very stony roads, where I've to install "the hard way" from source p.e. the installation of zim...
I discovered SBo for myself just 4 weeks ago and after one hour I was convinced. :D
Because of this thread i try today Sbopkg the 1st time and find it also very comfortable, so I will use it in future. :)

I've used it to quickly install flash, openoffice, web-corefonts and a few others. It's a nice app, and I'm glad it's there.

It's a bit of a pity it's not as simple as slackpkg. The ncurses interface is a little mammoth. I keep forgetting it takes up so much space, via old sources and pkgs, as well.

Still, glad it's there.

I will have to try out sbopkg at some point, I prefer to manually run slackbuild scripts. It does sound like a worthwhile application. :)

I've also been manually running and organizing slackbuilds that I download until 12.2. Getting all the packages rebuilt and installed on Slackware64 has been much easier thanks to Sbopkg, so I think I will stick with it.

I personally like compiling from source. It's very interesting to me. I've been thinking about installing a package manager, but since I'm a slacker...

There is no Amaya 11.2 build script at SBo, so I'm assuming you edited the Amaya 11.0 script for SW 12.2. Maybe it did not build for you because you did not have raptor installed. What was your error?

Okay, I remember the Amaya debacle. But having said all that, SlackBuilds.org never given the guarantee that one build script will work over multiple upstream versions. Granted in probably 80% of the cases this probably does work, Amaya clearly was not the case. I think several others agreed with you in the irc channel that the script could do with a bit of touching up. [1]

Sure you are entitled to your opinion. :) Noone said you weren't allowed to. However:

One SlackBuild is not "many", in my opinion. But alas perhaps you had more problems than the rest of us. All in all, SlackBuilds.org is a project done by humans (and an alien or two), so not all of us are perfect.

I can only say, I hope your experiences with SlackBuilds in general will improve. :)

Also, if you don't have any luck with SBo, I can recommend alienBOB's repository where he has a buildscript and packages for 12.2 and a 64bit package.

-M.

[1] - We'll not mention raptor. ;)

I also ran Amaya with the SBo script for 11.0; which was written to into /opt.

And, yes, I had raptor installed before running the Amaya SlackBuild.

The only one in the IRC channel who agreed that the Amaya build script from SBo
could use fixing was Alien Bob, which is why you see the script and package in
his repository now. Also for 13.0 ...
Again, the OP had a simple question. I'm not going back to find other SBo build
scripts that didn't work; waste of my time and yours. Every time I brought up a
problem with a SBo script it was just like now ... some guy trying to defend the
script at all cost.

My last comment on this thread ... if you like SBo, use it. The OP asked for an
opinion, I gave mine, and it's worth all you paid for it.

Regards,

I think Sbopkg is the bee's knees. I wrote about it for Linux.com last year and Chess has improved the program remarkably since then.

I used to manually manage my Slackbuilds.org builds, but now I use Sbopkg nearly exclusively. I really like that I can read the README files, find the dependencies, and then cue them into a good build and install order so everything runs automatically.

It's the perfect blend of compiling software by hand and automating package creation and installation.

Regards,

-Drew

@Murdock1979, yr right! I only just found out about sbopkg tool with the release of slackware 13.0, ha ha I feel like I am late to the party. but yeah, I fully agree, this tool has become my favorite new thing =)
I will say this about sbopkg, I never knew it existed, I always downloaded the individual slackbuild tar.gz file + the sourcefile directly from each tool's webpage @ SBo, then untar'd the slackbuild tar.gz file, move the sourcefile into the directory and bam, run toolname.SlackBuild application installed. I almost feel like happening upon sbopkg was a fluke, I think I saw someone here talk about it, or something. I tell ya what though, looking @ SBo's HOWTO, the SBo FAQ, and the SBo "SlackBuild Scripts Usage HOWTO", NONE of them mention sbotool once, ANYWHERE!? (aren't the guys from slackbuilds.org the ones who originated sbopkg tool?!?)

anywho -- from reading the SBo HOWTO I always thought there was this app called "chemtool" ?!#@! that HOWTO references chemtool allover, to this day I just suspect "chemtool" is a term/substitution for the actual packname name? I have no clue (still), but it always threw me off... anyways, what I am getting @ is that yr right, sbopkg has very low visibility, and I agree with you that it is one of the best tools available for slackware (really, it just makes building packages easily - I still would suggest a newbie get familiar with how-to manually build yr slackware packages from source, etc... then once u get a feel for HOW slackware works, then feel free run with sbopkg). now that I am on slackware64 (13.0), and I first read about using ARCH=x86_64 I was doing that for each package! I would do the whole manual thing with adding the "ARCH=x86_64 ./packagename.SlackBuild" to build from slackbuilds, hey everything worked but it became a bit tedious.

NOW though, everything is sooo easy = added the "export ARCH=${ARCH:-x86_64}" to /etc/sbopkg/sbopkg.conf, and everything has been a breeze. just wanted put in my .02 cents =)

peace

Using it now and have used previous versions, was even able to report some bugs to chess that he took care of.

I was never trying to defend the Amaya SBo script in any way, but rather the general quality of SBo scripts. While you are right that it would not be a good use of time to go back and rediscover the scripts you had trouble with just to post back to this thread, it would have been nice if you had posted these troubles on the mailing list. If no improvements were made to them, at least we could be aware of the "bad apples" to avoid.

At any rate, it should be noted that even if the SBo repo has some shoddy scripts, you can edit/fix them within sbopkg or even use different repos entirely. Yes, sbopkg can use different repos! This great tool has become more and more flexible over time.

No. It started as a pet project of Chess who at the time was not a SBo admin. People of the SBo mailing list contributed code and ideas and eventually the project was officially born. Later more developers joined the project and Chess did join the SBo admin team. If you read the mailing list archives you can see the story unfold...

Still, sbopkg is not in any way endorsed by SBo, which is probably why it is not recommended on SBo.

It should also be noted that you can export useful vars like that in your shell environment. This would be useful, for instance, if you occasionally still wanted to run a SlackBuild manually.

I tried it out today and it worked quite well for me. I built gnucash with it because it has 20 dependencies and I would therefore get to test out the queue. The first dependency wasnt in the repository, it had been updated and moved. I wound up manually installing that with a slack build but the rest of them worked. I had to update the slackbuild to the right version and it went through.

Great job contributors.

sbopkg is a great tool, makes managing software easier on slackware.

I have to remind myself to edit the slackbuild scripts for some custom options. But it's not too way off from the actual process of installing by source (you have to unrar the source, check the configure options, manually include it in the script etc etc). It's normal though, just the way the scripts are meant to operate, installing using default or pre-selected options.

A few suggestions for sbopkg :

- include an option to uninstall packages in the "List installed packages" section. That should make sbopkg complete in a sense, just like the ability to restore sets in a backup application.

- include an option to rename scripts which have been edited, saving in another location other than the default (1 copy of local). I just have to remember the name of the script and don't have to go through diff. Package tag similar to the name of the edited script would be added bonus.

Overall, it's an awesome utility. I'm using it now!

IIRC, you don't need to do that with the latest version. It actually checks uname to see if you are running a 64bit kernel. If so it will automatically change your build arch.

Love it, makes things very simple. I was having problems getting LMMS to build and was referred to slackbuilds by another user on these forums. Since then I've used it for countless other programs, and as long as I pay attention to the listed dependencies, I never have a problem using the scripts.

I read your review of sbopkg; and I have been using it ever since. The fact that you can setup a build queue and have sbopkg compile all the packages one after the other is a great time saver. It also comes in handy to check for updates for my slack-builds.

I actually only started using it with the release of 13.0, but my first thought was why I was just now using it. It's an absolute time saver.