SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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 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
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...
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.
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?
The last Slackbuilds.org script that didn't build properly was Amaya.
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:
Quote:
Originally Posted by Bruce Hill
Of the Slackbuilds.org scripts I tried, many were bad.
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.
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.
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.
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.
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.
@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 originatedsbopkg 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 =)
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.
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.
[...]
(aren't the guys from slackbuilds.org the ones who originatedsbopkg tool?!?)
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.
Quote:
Originally Posted by agentdcooper
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.