You have not used it yet, so you cannot judge it yet. Try it and you will understand it. Do not be like most people and judge it based upon what you hear about it. Bad things are thrown around about Slackware all the time, and it is not tolerated here in the Slackware forum. You will surely get flamed for anything like that. You must try it first and use it for a while, and then you can complain.

This has me confused:



'sbopkg does not do any dependency checking'
'sbopkg has the queuefile'
'sbopkg will build and install everything in the right order'
'determining the dependency order is still left to the user'

Now I don't doubt that chess knows what he's saying, and that it makes sense when you understand things, but from my limited knowledge, the above seems to contradict itself several times. If S does *not* do any checking, then what *does* it do when it builds and installs 'everything' in the right order? And if it does do everything in the right order, what does it mean to say that the order is still left to the user?

And, if sbopkg can infact take care of dependencies, how is it that we are talking about Slack *not* having DR? Does it, or doesn't it?

And another thing :-(

How/why is it that building a package from SRC somehow solves problems? I'd have thought that if I get a binary from somewhere and install it, that the end result would be identical to me compiling the same binary from SRC and installing it. How is it that compiling it 'here' is better/different than compiling it 'there'? In my DOS days I was a pretty good C coder, but it seems that in Linux things are just totally different, my old knowledge is actually working against me. It usta be that it didn't matter who compiled the code, the binary was identical. I want to understand this whole scene. Can someone point me to some document that will give me a foundation level understanding of all this stuff? Is there some excellent book that someone can recommend? Trying to build my understanding of Linux by going from being a Mint user and digging 'down' ain't working, gotta start from the bottom.

Again, you can compile things with some optional features or dependencies enabled or disabled. You can also compile things for your native architecture, which provides some performance improvements. You can also compile them with safe CFLAGS which may increase stability. For example using '-O3' can cause programs to crash, while '-O2' (the default for most sane distros) is safe.

Here is one concrete example, compiling mesa with '--enable-texture-float' enables floating point textures, a feature of newer OpenGL standards that they are afraid to turn on by default because of possible software patent issues.

I haven't compiled gnash in a while, but you could compile it either with ffmpeg or gstreamer. I usually used ffmpeg because it was more stable.

You misunderstand. sbopkg will just build everything in the queuefile, in order. This is the "right" order if and only if the user is "right" (but then, the customer is always right, right?)

The stuff in the queuefile doesn't all have to be interdependent. They can even be totally unrelated but sbopkg will build them in order anyway. This is a good thing.

Also, you just aren't up to date on how packages are built. They all use sophisticated tools like autotools, cmake and scons that detect what potential dependencies are present on the system where they are being built, and then chunks of functionality are enabled or disabled based on what has been found. *This* is where hard package dependencies come from, based on what else is present on the packager's system, *not* from the original source (because if the *source* had an unfulfilled requirement, you wouldn't even *have* a binary). If you move those binaries to another system, some of them may not work, depending on what is or isn't installed on the other system. And if you've installed something else that's an optional requirement but the packager didn't have it? Then you're out of luck. But if *you* build from source on the system where *you* will use the binaries, you are making binaries tailored to what else is on *your* system.

Read this about sbopkg's queuefiles:
http://www.sbopkg.org/queues.php

Yeah, the clarification is that the queuefile has to user-written. (SBopkg has an interface that allows you to add packages to a queue one by one and then save that queue). It doesn't have to be written by you, however, because there are archives of prewritten queues.

Slackware does not have DR and sbopkg is not able to resolve dependencies either. To make things easier sbopkg has the ability to use queue-files. A queue-file is nothing more than a text file that contains the names of packages (or other queue-files). sbopkg builds one by one. So after you have resolved the dependencies for software you want to install you can put them into the queue-file for later use.

I wrote a post not long ago (based on knowledge garnered from other Slackers), about the use of sbopkg with queuefiles:
http://www.linuxquestions.org/questi...ml#post4724019

Yes, I suppose I was not very clear in my earlier post, sorry about that. But the replies above explain it well. Once you get a handle on how to use slackbuild scripts from the slackbuilds.org repository, then sbopkg will probably make more sense. Reading the documentation on slackbuilds.org is critical, as is reading the sbopkg man page and other documentation. Sbopkg just tries to make using the slackbuilds.org repository a little easier by essentially offering a front-end to the repo which you may or may not find helpful.

I guess my question was whether the -i switch with sbopkg would automatically download a queue file from one of the available repositories, similar to how slackpkg will use a mirror which I specify to download packages from the Slackware tree. It's weird, until now I never looked in /etc/sbopkg...I don't know why. I like to keep a sperate /packages repo on my file server, I could have just been editing OUTPUT all this time.

Anyway I have some homework to do apparently especially after reading this thread. Yeehaw! A new Slackware adventure!

By now, it's certainly been answered. You make or download the queues yourself and put them in /var/lib/sbopkg/queues. That's where they're found.

We need to make a sticky post (possibly just a link to a LQWiki or SlackWiki article) about how package management in Slackware is done these days. I'll try to take care of it by the end of the week.

LOL, yes, I understood queue files, I just thought what was being said was that sbopkg would find queue files which I didn't have locally. I now understand that they either have to be created by the user or downloaded from some repo. Thank you.

I begin to understand. Compiling is 'personal' to one's machine, and one's environment. And I take it that it's possible to take some dependency and static link it rather than dynamic link it just in case one does not need/want some library floating around seperately?

B-b-but ... surely that *is* DR, is it not? The dependencies for something are figured out, put into this queue file, and that makes sure that they are all built and installed. That's what I'd call DR. Or maybe I should say that that's what I have presumed DR is all about--a list of things that need to be installed along with the primary program. What else could there be?

Sorry guys, you've been very helpful all, I need to do some reading before I ask more questions, I think I'm wasting you guy's time right now.

The difference is that sbopkg actually builds the packages in the order of the queue and installs them immediately after they are built.

You can look at it as somewhat like Gentoo's emerge if you squint really, really hard.

Slackware's package manager couldn't care less about that. If someone else built the packages for you, you could installpkg any or all of the packages in the sbopkg queue list and installpkg would not stop you from installing only the last package in the queue.

(edit: Meh. I should read more than the last message. Others have answered this quite well, I think.)