LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   How do you gurus just know what to install and how to install? (http://www.linuxquestions.org/questions/slackware-14/how-do-you-gurus-just-know-what-to-install-and-how-to-install-700971/)

OverlordManny 01-30-2009 03:15 AM

How do you gurus just know what to install and how to install?
 
Ok let me start this off by saying I'm not a GNU/linux noobie. I have been using linux since hmm. 2002, 2003? Whenever Mandrake 6.0 came out. It was my first time I dumped windows for linux. I still use windows for D3D games but.. I piddled with Redhat v?? before that and have since went on to use Suse, Fedora Core (very briefly), Solaris (not a GNU/linux but still a *nix), Mandriva, Ubuntu, I built an LFS (by the book mind you but with BSD init), and just in the past two months Slackware. I have to say those years using the other distros weren't nearly as educational as living in Slack-land. With the exception of Solaris and LFS, I was never truly FORCED to use the CLI nor did I HAVE to build apps from source. I find my self driven to learn how and why the linux based OS operates. Unfortunately I'm getting discouraged. I'm at a loss when it comes to building dependencies that have their own dependencies. How do you guys learn it all?

There are literally millions of packages out there and so many depend on another one, config flags have to be set to allow one to talk to another. For example I want to build VLC media player, I have used it for years on windows and other distros and it is my favorite media player,but I have no clue where to start building it. I have downloaded all the deps that are listed on the VLC site but I don't know where to begin, what to install first, what compile flags to set. I know that I could use slackbuilds to build it but that would defeat my purpose, I want to learn this OS. So tell me where do you Great Ones get your knowledge? Where do you find out that libA won't work with appB unless patched with patchC? Am I missing something somewhere? I mean I can't imagine that anyone could have all that knowledge and still have a personal life. (Not meant as an insult, lol)

Alien Bob 01-30-2009 03:32 AM

Quote:

Originally Posted by OverlordManny (Post 3426093)
Ok let me start this off by saying I'm not a GNU/linux noobie. I have been using linux since hmm. 2002, 2003? Whenever Mandrake 6.0 came out. It was my first time I dumped windows for linux. I still use windows for D3D games but.. I piddled with Redhat v?? before that and have since went on to use Suse, Fedora Core (very briefly), Solaris (not a GNU/linux but still a *nix), Mandriva, Ubuntu, I built an LFS (by the book mind you but with BSD init), and just in the past two months Slackware. I have to say those years using the other distros weren't nearly as educational as living in Slack-land. With the exception of Solaris and LFS, I was never truly FORCED to use the CLI nor did I HAVE to build apps from source. I find my self driven to learn how and why the linux based OS operates. Unfortunately I'm getting discouraged. I'm at a loss when it comes to building dependencies that have their own dependencies. How do you guys learn it all?

It is a matter of reading the documentation that comes with the sources, talking to developers and other users and such. Or look at the repositories of http://slackbuilds.org where we require a README file which has to list the dependencies for the software we have a SlackBuild script for.

Quote:

There are literally millions of packages out there and so many depend on another one, config flags have to be set to allow one to talk to another. For example I want to build VLC media player, I have used it for years on windows and other distros and it is my favorite media player,but I have no clue where to start building it. I have downloaded all the deps that are listed on the VLC site but I don't know where to begin, what to install first, what compile flags to set. I know that I could use slackbuilds to build it but that would defeat my purpose, I want to learn this OS. So tell me where do you Great Ones get your knowledge? Where do you find out that libA won't work with appB unless patched with patchC? Am I missing something somewhere? I mean I can't imagine that anyone could have all that knowledge and still have a personal life. (Not meant as an insult, lol)
It all boils down to experience and long periods of testing. All that knowledge is then condensed into a SlackBuild script so that subsequent builds of the software are easier, plus, a SlackBuild is in fact a document on how to build software.

In the case of VLC, it has so many dependencies that it takes a long time to get the resulting package right. You can start with running "./configure --help" in the VLC source directory and examine the possible options. That will give a good indication of what external software can be used by VLC. Once you know what you need before compiling VLC itself, you will have to retrieve all these programs and compile/install them into binary code which VLC's configure program can pick up. That way, the external program's functionality will be enabled in the resulting VLC program. Either you pre-install these external programs on your computer before you compile VLC, or you build all these external dependencies right into the VLC package itself. I chose for the second option and built static libraries for all these dependencies (ffad2, faac, lamemp3, dvdread, etc...).

If you want to build VLC the easiest way is to grab my SlackBuild script for it. If you take a look at the SlackBuild itself, you'll understand why it is not easy to create a full-featured package for VLC.

The SlackBuild script at http://www.slackware.com/~alien/slac...vlctest/build/ will compile a vlc package for you that does not depend on any other non-Slackware software (except for the libdvdcss software which you additionally require to play encrypted DVD's).

Eric

Randux 01-30-2009 03:52 AM

No guru here, just a confirmed Slacker.

As you found out, most distros hide what's going on and when you have to do anything you find yourself lost and helpless.

Welcome to SLACKWARE! Now you will learn LINUX!

First step is to do ./configure --help

and read over the options. Then you get on the internet and start searching for hits on the dependencies, go to their websites, read, read, and try stuff. Most of the time it's obvious from the configuration options what you want and what you don't want. Sometimes stuff wil break and not compile. Then you have to go read forums for stuff like ffmpeg, etc. and find out that you have to apply patch so-and-so for such-and-such a problem. It's time consuming and you have to be organized but you don't need to be a rocket surgeon. You can also ask here and on freenode #slackware (however there is a much higher noise level on #slackware) than there is here, lots of off-topic BS from guys who truly don't have a life. However, many heavy-duty Slackers like Robby and Alien BOB do hang out there.

That's enough of my time you took up, I have a personal life you know! :p

OverlordManny 01-30-2009 03:53 AM

Quote:

Originally Posted by Alien Bob (Post 3426102)
If you take a look at the SlackBuild itself, you'll understand why it is not easy to create a full-featured package for VLC.

No kidding man that thing is a beast, lol. Hmm Maybe I'll use your slackbuild after all. I'm just very concerned with wanting to do as much as I can myself, that way I'm learning more. That's why Slackware has become so attractive to me lately after all.

I've been building slack packages of all my installs, ZSNES, wicd, aMule, etc, because I desire clean removal of my installs but, lol, I'm nowhere near fluent enough to generate a script like this.

Thanks

OverlordManny 01-30-2009 04:12 AM

Quote:

Originally Posted by Randux (Post 3426116)
As you found out, most distros hide what's going on and when you have to do anything you find yourself lost and helpless.

Please don't misunderstand me. I'm pretty well versed in the CLI and I have a pretty good handle on scripting and most other things. I can survive pretty well without a gui at all. It's mostly the idea that packages dependencies change often from version to version and their dependencies change as well. Sometimes it feels like I'm in an endless loop. But at least with Slackware it's not quite "dependency hell" like in other *nixs. Thank goodness. That and Slack using a vanilla kernel is great too. So much easier for me to update.

Generally what you have suggested is what I do; looking up and reading about dependencies and such, even if I don't always totally understand what I'm reading, lol. I guess just looking at VLC is quite intimidating to me because of the large amount of dependencies. Thanks for your tips. I appreciate it.

Randux 01-30-2009 04:21 AM

I don't agree with alot of the way software is viewed in the *NIX world but it has enough other advantages that I can live with it. You pointed out a very sore spot that is ongoing which is how to keep an app stable when it depends on functional pieces that are not under the control of the app. This is true with Linux generally and to less extent with BSD (but the same extent with BSD apps as opposed to the OS).

I built VLC from source without scripts more times than I would like to remember and it and many other big apps can be a royal PITA. I remember one time I had to have two versions of gtk+ built because of conflicting demands from other stuff I wanted. I wasn't smart enough to figure out how else to deal with the problem, so I would install the gtk+ I needed, build the app, then install the other gtk+ on top of it so other apps would work.

It can be frustrating but it's mostly just toughing it out and building piece by piece. I remember cursing and recursing alot building some stuff. I start a ./configure and it breaks because I don't have dependencies A & B. I go download those and building them I find I don't have other pieces. Sometimes the configure doesn't tell you everything that's wrong and you get to do this a few times for one app. Then you do those and then return to what you were building. It can take awhile but finally you finish it.

You are right that a main benefit of Slackware and Pat's brilliance is not making it worse by forcing dependencies on you. If you want it on your system, build it. If you don't, don't. Compare Slackware to even a very nice BSD with a packaging system and you will see how much cleaner you can make Slackware and have everything just work.

Franklin 01-30-2009 06:34 AM

Quote:

Originally Posted by Randux (Post 3426132)
I don't agree with alot of the way software is viewed in the *NIX world but it has enough other advantages that I can live with it. You pointed out a very sore spot that is ongoing which is how to keep an app stable when it depends on functional pieces that are not under the control of the app. This is true with Linux generally and to less extent with BSD (but the same extent with BSD apps as opposed to the OS).

The role slackbuilds.org plays in making this task easier for the average Slackware user cannot be overstated. It's taken me seven years to reach my current level of incompetence. The collective experience of ALL the contributors of scripts to slackbuilds.org makes the work of tracking odd-ball dependencies and their version changes much easier. Not only do you have the maintainer tracking the software, but any user can post a heads-up via the mailing list. It's taken the whole slackware experience to a new level.

The site has become so valuable that it should have some category in the yearly poll such as "most valuable resource". I would even go so far as to say it makes Slackware the Distro of the year with respect to the change in user experience - not just because it's my favorite Distro.

I could go on, but since I'm "preaching to the choir" I won't.

GazL 01-30-2009 06:43 AM

When you build for yourself, the amount of dependencies and difficulties in building become part of the decision process about which software you choose to install. If there were no packages or dependency systems and users had to build everything for themselves then I get the feeling it would encourage the bigger projects to put a little more effort into reducing their dependencies and being easier to build. It'd probably also encourage the distributions to stick with a standard set of libraries+versions (yes, there is the LSB, but it really doesn't go far enough).

Imagine if everyone had to build Gnome for themselves. Would it really be as nightmarish as it currently is? My feeling is 'no... because no one would use it if it was'.

This is the downside of the amount of 'choice' we otherwise enjoy. Windows and OS-X have the advantage of a known set of libraries and library versions for developers to use, but even there many windows programs still have to ship with their own dlls.

Perhaps if the LSB standard was more ambitious/aggressive, and some library consolidation took place, then things would be a little easier all round, but unlike a corporate entity there's no one owner to mandate the independent library projects consolidate, even where it'd make perfect sense.

arfon 01-30-2009 08:13 AM

The Arfon method of package dependency resolution
 
The Arfon method of package dependency resolution-

Since I, by default, install EVERYTHING that says 'lib' off of the Slackware CDs, I don't bother downloading 'required packages' for any application. I have found that many times, Patrick has taken care of that for me. So, here's how I build my stuff-

Compiling an app-
1) Download the source for what you want, IGNORE the 'required packages' info.
2) Try and build it. If it builds, you're golden. if configure or make complains that BLAHBLAH.so isn't installed, just grab those and install them.
3) Repeat step 2 until your application successfully compiles.
Installing a pre-built app-
1) Download the app/package and install it.
2) Run the app FROM A TERMINAL WINDOW (if in X). What this does is it allows you to see what the app complains is missing. If it runs, you're golden!
3) Install the missing required packages and repeat step 2 until the app quits complaining and runs.
Why do I do this and not just D/L and install required packages up front? Because, I want to keep my boxes as close to a clean Slackware install as possible so when I build packages, other Slackers can use them.

EXAMPLE: If Slackware 23.7 has Qt 7 in it but I installed Qt 9, packages I build probably won't work for other Slackers...

H_TeXMeX_H 01-30-2009 10:24 AM

What I do is:

1) I run './configure' then I look at the output. It usually tells me what I'm missing.
2) I then run './configure --help' and look at the options to see if I can or want to enable or disable anything.
3) Install needed dependencies starting at step 1 above, then try to configure the main program again.

Repeat until configure succeeds then run 'make', 'su', 'make install'.

rc nai 02-01-2009 01:23 AM

I thought if I ever wanted to install a specific program that wasn't available for slackware, my first intention would be to make sure that it would work side by side with slackware's package management tools--which is very important to me. I think by doing make and make install is ok sometimes as long as it comes with make clean. Anyway I have never learned how to build a slackbuild package before. But today after reading this thread, it gave me a new approach. I started off reading these:
Code:

http://slackwiki.org/Writing_A_SlackBuild_Script
Code:

http://slackbuilds.org/guidelines/
And the next thing I knew, I submitted my first slackbuild script for naim to slackbuilds. I just hope it gets approved :o It works by the way on my test machine.

You ask, how do you know what to install and how to install?

You probably already know this but I'll say it anyway. Personally from what I've learned so far and as an example, whatever program that I want to install that's not available for slackware I would go to the official website and look for the required libs and dependencies that's needed to run that program. Then I would note down those libs and dependencies. With that in mind, I would do the same thing and go out and try to find out what is required to run those dependencies. If there isn't any, then that's a good thing. On to building the slackbuild script starting with the dependencies then onto the actual program. By extracting the source tarball, you can read the readme file for additional requirements and like the others had mentioned, use ./configure --help to pass extra options, and from there it's just a matter of setting up the slackbuild script to comply with slackware's package management tools. Then you can use its tools to install and remove the package i.e. installpkg and removepkg.

I'm thinking that's how the few slackware "gurus" do it. Yes, no? :scratch:

dividingbyzero 02-01-2009 04:38 PM

Just read the README that comes with the program in question. Most things I install are just './configure, make, and then make install. I usually read the INSTALL or README and it says depends on this and that and then I just download and compile those particular libraries or whatever. It's easy.

arfon 02-01-2009 05:15 PM

If at all possible make Slackware packages using Src2pkg. If you ./configure;make;makeinstall; it's ALOT harder to remove stuff that sucks.

Try building with src2pkg first, and install the resulting Slackware package.

dchmelik 02-02-2009 02:23 AM

Install by the menu (for groups of packages,) not 'install all,' and read everything
(in v12 and up there are about 10 times more X Window system packages--I guess they separated some stuff out--so just read them once or twice and memorize what you do not need, like the other package series.)

Try swaret, slapt-get, slackpkg, sbopkg, linuxpackages.net (Slackware-specific,) and 'generic' packages. Then become familiar with, if still necessary (like for generic packages,) installpkg to try new stuff--and removepkg to get rid of old stuff.

As someone said, do './configure.' I cannot say much else except sometimes you will have to read/grep something like 'config.log,' and if you ever studied Computer Science or are interested you could try fixing some bugs (if in software you like.) See what will work and not when you have certain packages not installed (more for dependencies of packages rather than source, which should say when compiled, and the next dependency will say, and so on....)

Make a kernel, maybe even if you have no new hardware that the kernel has no driver(s) for. Even make a kernel 2 or 3 times a week for 2 or 3 years (well, maybe not every week.) I did that (100 - 150 kernels) when on my pIII I enabled Matrox G450 dual-head, and tried to enable more things for it to do.

Try such things on various POSIX systems like NetBSD (the oldest updated BSD, like Slackware is the oldest updated Linux) and maybe Open Solaris (which at first was too hard to download & install so I have not been back,) based on another old Unix.

If you really want to learn how to choose packages, try Debian (or Ubuntu or Gnewsense,) or at least an old version, so with Apt you can choose hundreds - thousands in smaller groups (often individually, and probably more than Slackware) than Slackware's installer. Apt is or was not an enjoyable experience, but it would also mostly answer your question. If you install almost the entire Suse and try everything out it is probably another way: it was on 3 - 7 DVDs 8 years ago (maybe it was CDs, but I will call them all CDs now that there are audio-DVDs.)

--David

H_TeXMeX_H 02-02-2009 07:16 AM

You can also use paco to manage installs, it was designed for LFS, but it works well in any distro.


All times are GMT -5. The time now is 12:37 AM.