Robby and Erik's packages are the only trustworthy packages (at least for a lot of people) currently out there for Slackware that come in a pre-built state.

Dependency resolution would seriously break Slackware down and even create a monolithic project that would consume a lot of resources. Look at Debian as a prime example. The project is big and many people contribute, but Debian's stable releases are few and far between. Even Ubuntu which is based on Debian has many problems that carry over from the various unstable releases Debian provides. Software is either untested, unstable, or has bugs that simply can not be solved on the maintainers' end without going got the original developers, and in this problem lies the problem of why Linux is not a mainstream OS as much as Windows and Mac are.

If you have a problem with a package on Linux, there is not central point to submit a problem to and have bugs fixed in updates and hotfixes. Yes you have maintainers who work on the distribution, but they have limits they can do such as supply patches to existing problems that may or may not solve the problem in total. You have to go to the original developer which may or may not be so willing to acknowledge they have a problem, or has abandoned the project entirely leaving nothing but an open source database to which people can apply patches through using a build system.

For Slackware, look at the size and volume of what has to be dealt with. If a bug arises in Slackware, it's easily found, squashed, and patched over while a bug report is also sent back to the original developers for analysis. In this way, less is more. How so? Less software to deal with means more quality that can be focused on in terms of stability, reliability, and user friendliness.

By relying on SlackBuilds this also creates a wider community and provides a standardized built system for the project to where Erik, Robby, SBo, or Patrick can centralize an effort and remain on a common ground in how to build something.

And actually, SlackBuilds do have dependency resolutions. You just have to go to their website, read the page for the software, see what is needed, and manually resolve the dependencies yourself, or see what error is generated when you run the SlackBuild script for what exact file(s) is(are) needed.

5 members found this post helpful.

When you install open source software, you have to deal with open source spirit

A programmer use function from library designed by other programmer, etc...

It can appears painfull for install the program and its dependencies but personnaly I like the way the program borns from those various sources. Also there is choice, I mean I tend to not install programs that use libraries which will be never used by other programs in my system, I try to install programs with usefull libraries whenever it is possible

--As they have told you, there are some third party repositories you can use.

--You can compile from source manually.

--You can take packages from other distributions and turn them into Slackware packages (may work, may fail, use at your own risk!).

Personally, I prefer using SlackBuilds and, occasionally, manual compilation. When you live with a very crappy Internet connection (2 Kps or so), the Slackware method of getting the SlackBuilds and solving the dependencies by hand in a cyber-cafe is better than trying to use an on-line repository at home. I agree that installing some apps can require more work, and that time spent compiling can be too much, but "SlackBuilding" allows me to patch the packages at the time of compiling or configure compiling options, so I think advantages beat disadvantages. I spent 5 days setting my first Slackware installation up, but once I did it, I stopped worrying about the software management except for security fixes.

Exactly! Community repositories use to be untrustworthy, or unreliable, make for slow development cycles and have many problems. Their advantage is that they allow easy installations (just click, and everything is handled automatically). However, they are not as flexible as my own self-compiled packages, which can be manually updated, patched or reconfigured by myself. Many packages in Debian 6 contain very nasty bugs, which would need an update to get solved... but, when you update a given package in an unofficial way, you introduce a layer of complexity in your system and risk breakage. With and SlackBuild based system, tweaking and solving these problems is dead easy.

If the original posted wanted to have alternatives to the SlackBuilds, then there are many. If he wanted dependency resolution, then it exists (more or less). However, package management in Slackware is intended to be basic (in the geek sense) and most slackers prefer it this way.

firekage, I understand your frustration. Years ago when I first started with Slackware I was frustrated by the lack of a large central repository. You can read my frustrations on line if you find my web site.

Back then slackbuilds.org did not exist. I don't think slacky.eu existed either. Eric and Robbie were not yet on the Slackware team. I don't think either offered any packages back then. The primary place back then to find packages was linuxpackages.net.

Part of my frustration --- and I think yours as well, is building packages is a new concept. Anybody coming from Windows or Macs are accustomed to just downloading and installing software. That world exists with the very large distros, at least those based on Debian or Red Hat. Just about everybody else struggles to build a large repository.

There is a lot of maintenance required to maintain such a large repository. A single person can never handle that kind of burden. Even with the large central repositories, there are hundreds of people who contribute to maintaining those packages. The same would need to be true if there was ever to be a large central repository for Slackware.

Then there is bandwidth and the costs associated with hosting packages. Somebody has to pay for that storage and for the bandwidth used by thousands of people downloading packages. That is a primary reason why the maintainers of slackbuilds.org don't mess with prebuilt packages --- money.

Robbie and Eric hosts prebuilt packages at their own expense.

Eventually I grew to accept that a large central repository is unlikely to happen with Slackware. Possibly some day the major contributors will pool resources to form such a repository, but until then the current process seems to work well enough. So part of the being a member of the Slackware community is to accept this fact --- there is no single large central repository of prebuilt packages.

For my first few years of using Slackware I learned to live without various packages because I did not know how to build packages from build scripts. We all have our own busy lives to maintain and therefore all learn at our own pace. One day I decided I was ready to learn to build a package. Yes, the process was frustrating. As you noted, if the provider of the build script does not list the dependencies, then the process is discouraging. I don't think that is a problem any more. All contributors of the major repositories now provide that information. All we need do is read.

Yet that too can sometimes be frustrating. Occasionally a package might require a dozen dependencies. Those dependencies have dependencies too. Building a single package could require building two dozen or more packages. Not fun!

Times have changed. As mentioned by several people, sbopkg can help a Slackware person automate the building of a single package. Sure there is a learning curve but you have shared that you use Slackware because you want to learn. So you have half the battle won already.

I struggled for several years with the concept of having to build my own packages, but today I seldom give the idea a second thought. Other than the stock packages that come with Slackware, I can't remember the last time I installed a prebuilt third-party package. I always build my own even when a prebuilt package is available. Instead I download the build script. The process has become second nature to me. In hindsight I have to smile a bit because I never envisioned myself being that way when I first started using Slackware.

There are some tricks to learn as you have discovered. One trick is to ensure tmp space does not fill beyond capacity. My solution to that problem years ago was to insert some simple commands at the end of every build script to clean tmp space of the build process. A few years ago I began using tmpfs as my tmp space. I think only twice I have run into building a package that needed more space than I have in tmpfs. For those couple of times I revised the build script to build in an area large enough to host the build process.

Regarding the time required to build packages, yes, sometimes they take a while. Generally, the bigger the package, the more complicated the package, the longer the package requires to build. I have been building my own KDE3 and Trinity packages for a couple of years now. Building the basic suite of those packages requires several hours. There is nothing that can be done about that. I open a terminal, su - to a chroot build environment, run the scripts, and then ignore them until done. With a dual core system I can do that. Just as often, I let the packages build and go to bed or power up my home theater pc and watch a movie.

I don't think the build process gets any shorter. In Slackware 12.2 I could recompile my own 2.6.27.x kernel in about 16 minutes. With 13.1 and the 2.6.33.x kernel I need twice that time. I can't change that. I just let the packages build and go on with other things.

By and large you will find that most Slackers enjoy building their own packages. Lazy Slackers tend to do without when a prebuilt package is unavailable. Once upon a time I was a lazy Slacker.

An option you might consider is to download glsapt. Gslapt is a graphical package manager for Slackware. Gslapt works much like the Debian graphical package manager. Gslapt is a frontend to slapt-get, which is a command line utility for downloading prebuilt packages. You can configure gslapt to search all of the trusted repositories for a particular package. That would reduce the number of times you might need to still build a package.

Slackware is one distro that, as far as the underlying system structure, has changed the least through the past two decades. That single constant is one of the features that keeps most of us using Slackware. I've been known to share my opinion about ways I think Slackware could be improved. Sometimes some of those ideas become reality and just as often not. Yet I still use Slackware for all of my computers I own. Maybe there is a message there.

Sit back, take a deep breath, and have fun. Many of us here who use Slackware have experienced some of your growing pains too. You aren't alone.

9 members found this post helpful.

oneday i realized, using slackware make your life worthed. Learn is not an easy choice

slapt-get also supports and uses dependency data that may be embedded in the package description.

I started with Slackware around version 10. I had to build most things from source if they weren't included in Slackware. I found that the "README" or other information included with the source packages was usually enough to successfully build on Slackware. To avoid a lot of work I stuck with the stable releases and had to build the software every six or eight months.

Some sites have packages for Slackware, though they may be for the previous stable release. Often they aren't dependent on the exact Slackware version or they include the required packages.

Take advantage of the Slackbuilds when you can. They save a lot of time and avoid the majority of the problems. Just the documentation that Eric creates is a great benefit for installing the software.

The good thing about Slackware is that it provides a solid base to build onto. If you want to install and use the latest versions of everything without much work, then a different distro may be a better choice. I've managed to keep relatively up to date using the "current" packages from Slackware and Eric's packages for KDE and multilib. I can see how building an office suite or multimedia package could be time consuming.

If you truly have a development environment where you need to install specific versions of certain packages then I recommend creating some baseline Slackware systems that you can start with. Make backup copies or use separate virtual machines, then use scripts to install or build what you need.

Two programs that I recommend are VirtualBox (free) and Paragon Hard Disk Manager (purchased). I use VirtualBox to test out builds and install packages before I attempt it on my live Slackware system. I use Paragon's hard disk backup software to save snapshots of my Slackware system so that I can go back to something good if I really break the system. Making backups could be even more important for other distros, since they update more frequently with newer versions. The downside to getting lots of updates and automatic dependency handling is the greater chance of something suddenly going wrong.

Slackware is purposely not like most of the other distros. In some cases that makes Slackware more difficult to update, and in other cases it avoids problems. Sometimes I get frustrated trying to install or build software but I try to remember that I suffered frustration for other reasons with other distros. From my point of view the two weaknesses of Slackware at the moment are KDE and the lack of multilib support. Since Eric has such a great job addressing those two things I am having no trouble using Slackware.

If you have problems building or installing software, ask for help. I've gotten answers for most of my questions, though not always the answer I would like. In a few cases I had to wait for Slackware to catch up to the latest versions and in others I had to install newer versions of software. Decide what you want from your Linux distro and then choose the distro that fits your needs. You may end up using more than one depending on the situation.

Share what you learn with other Slackware users. You may find some good solutions for handling the problems of installing and building software. I've made a number of suggestions and some of them have eventually had an effect on Slackware.

1 members found this post helpful.

Thank You for your replies. I will read all of them, and think about it, when i will have free time - i returned to home just now and realised that one of my hard disk failed (i accidentaly pushed my computer and he fell of from some height), so i don't have Slackware right now, but what's more frustrating, i lost all of my documents (work and health and so on) , passwords etc.

Store them in KeePassX (available on SlackBuilds.org), and put both the KeePassX executables (it's cross-platform) and data file on a thumb drive.

You could start another thread about hard disk data recovery. I can recommend a few things based on past experience.

Don't attempt to use the hard disk any further until you are ready to try and recover the data. Disconnect the power and data cables.

Get a new hard disk that is compatible with the computer and at least the same size as the bad one. A larger disk is OK. Check out the new hard disk and make sure that it works.

Whether you can recover any of your data is partly a matter of luck. If you are lucky, only a few spots on the hard disk are bad. You can make a complete sector-by-sector copy of the bad hard disk to the new hard disk.

Connect your new hard disk as the first drive, and connect the bad hard disk as the second drive. Use the "dd" command.

The "conv=noerror" option tells "dd" to ignore errors. You may find the none of the disk is readable, or that most is readable except a few sectors. The copy will take a long time depending on the size of the hard disk.

When you are done, the "sda" disk will be a copy of what could be read from the "sdb" disk. Now if you happen to have a third hard disk or some backup software that can copy sectors, make a copy of the "sda" disk. That way you can make multiple attempts to use data recovery software and start each one with an untouched copy of the disk sectors.

Power off and disconnect the bad hard disk and put it in a safe place. This is especially important if you don't have a third hard disk, since you may have to read it again. Sometimes data recovery software doesn't work well, and makes the data harder to recover. In that case you will want to start again with a copy of the bad hard disk (or the sectors from the bad hard disk).

You can start by using "fdisk" to see if there are partitions and then use "fsck" to check the file-system. If neither of those are able to see any partition or filesystem then you will have to use other data recovery tools. Start a separate thread if you want help finding data recovery tools.

If you are able to recover some of your data, copy it somewhere safe before you try to recover other files.

If you are unlucky then the hard disk electronics is bad or the majority of the disk is unreadable. In that situation you would have to use a professional data recovery service who can repair the hard disk or temporarily connect the hard disk assembly to working electronics.

2 members found this post helpful.

There are 2 alternatives:
- Salix Os
- Arch with pacman

PS:I hate automagically installations: for example, try to recompile libsoup without kde support on Arch. It's horrible.
SlackBuilds are so versatile.

You want to use Slackware because it's a good distro for learning Linux, since there's less hand-holding and it requires a more thorough knowledge of config & software installation.

But it would be better if there was an easier way to do things, more like Ubuntu, which is what you're trying to leave behind so that you can learn more about Linux?

Jut a minor, non-important point. That particular package is actually made on Slackware, not Salix (I know as it is one of mine) , not that it matters too much as it is a binary repack. As much as anything I contributed it to Salix so that there would be a readily available pre-packaged binary out there for Slackware users should they want it.

I am an Opera employee working in the Desktop team as a QA and a Slackware user to boot. I'm also currently the person who is primarily responsible for testing our official packages. Perhaps one day I might push for us to produce Slackware native official packages but at the moment we have quite a few important things lined up that need to take precedence, so this is the best alternative I can offer right now. They might not be official but I test them as thoroughly as I do our other packages.

P.S. I also repackage all of our public development builds and offer the latest ones publicly here. These will install alongside the stable version of Opera (not replace it) and use a different unique profile by default.

2 members found this post helpful.

In addition to packaging Opera for them, I follow what they do pretty closely even though I actually use Slackware day to day. I don't know where you got this idea but I don't believe there is any truth it it at all. If anything Salix is going from strength to strength.

A little offtopic, but:
ruario, do You have Opera-11.61 Christmas snapshot there(I'm using it on M$ Windows now - build 1222)? I want to try it on Slackware too, but I didn't found it there.