Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 12
Like Tree2Likes
I currently on Ubuntu distribution looking to perhaps try out slackware now that im better on the command line. The only thing that really puts me off is the dependency ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2005
    Posts
    14

    Lack Of Dependencies and Dependency Resolution in Slackware


    I currently on Ubuntu distribution looking to perhaps try out slackware now that im better on the command line. The only thing that really puts me off is the dependency resolution. Slackware is a distribution that believes dependencies are the work of the user which I find a strange notion.

    How do slackware users cope with this problem? Is it overly time consuming to get things to work, Are there alot of PPAs available for programs to solve this.

  2. #2
    oz
    oz is offline
    forum.guy
    Join Date
    May 2004
    Location
    arch linux
    Posts
    18,733
    Quote Originally Posted by Idris View Post
    How do slackware users cope with this problem?
    Hello

    Most devoted Slackware users like the fact that it doesn't resolve dependencies by default. You can use various utilities such as slapt-get to resolve most dependencies if you want to go that route:

    jaos.org - slapt-get
    oz

  3. #3
    Just Joined!
    Join Date
    Nov 2009
    Location
    Sweden
    Posts
    42
    If you do a full installation, you don't need to worry about dependencies, so there really is no problem.

    The lack of dependency tracking also makes installing software from source a lot easier. With other distros, you have to manually write lists over all the dependencies just to make sure the package manager doesn't delete them. You don't have to do that with Slackware.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Newbie
    Join Date
    Apr 2005
    Location
    Clinton Township, MI
    Posts
    104

    Here are some reasons that Ubuntu and Slackware exist

    Quote Originally Posted by Idris View Post
    I am currently on the Ubuntu distribution, looking to perhaps try out Slackware now that I am better on the command line. The only thing that really puts me off is the dependency resolution. Slackware is a distribution that believes dependencies are the work of the user which I find a strange notion.
    First of all, Ubuntu and Slackware cater to completely different audiences. Both are easy, but in a completely different way. Both are easy to install, but Ubuntu, once installed, makes a lot of choices for you. That is "easy" in one sense. When you do not even understand what a package is, it is nice to have a ready made system for you that takes care of routine system management for you. But once you learn how to handle such things, many times you want more control, and that is when people start looking elsewhere. Both distributions serve their purpose well.

    Quote Originally Posted by Idris View Post
    How do slackware users cope with this problem? Is it overly time consuming to get things to work, Are there alot of PPAs available for programs to solve this?
    Slackware is a classic distribution. It was created at a time when nearly all software was distributed, whether in binary or source form, using compressed archives. The "tar" in the name originally meant "tape archive", though it has been a few decades now since tape was a primary archiving mechanism. The technique works as well as it ever did. Compression is a means of making the archive smaller or more compact. There was Z compression, then gz compression, then bz2 compression. Slackware usually has .tgz packages, which are archives with gz compression.

    Concerning PPA, that is a term unique to Ubuntu-based distributions, a convenience tool for "Personal Package Archives". Slackware uses either binary or source packages in the .tgz form I described above.

    Others have mentioned that there are multiple package management tools available in Slackware, and a few Slackware derivatives use them as the primary package management tool. With Slackware, you CAN use them if you want, but pkgtool, which deals with those .tgz packages I have described remains the main tool, and someone explained why: many Slackware users and developers like to download source code packages in that .tar.gz or .tgz format and unpack them. The last thing they want to deal with is a chain of packaging dependencies. Of course, the cost is that you have to either get a package dependency management tool if you are simply going to install binary packages, and in that case, slapt-get is one such tool, and there are variations on it. But if you are going to build software using Slackware, then you just may find what Slackware users prefer: they would rather manage which software packages and their associated libraries themselves.
    rokytnji and PrinceSharma like this.
    Brian Masinick
    masinick AT yahoo DOT com

  6. #5
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,279
    How does this actually work in practice? I have on one or two occasions built from source and had the configure step fail because it couldn't find some library or other that it needed. Obviously that's not a serious problem; you hunt out source code for the library, and build and install that first.

    But do missing dependencies always show up like that? Can a program build and install successfully but then crash because some runtime dependency wasn't met? And, if so, how do you determine what the problem is?
    "I'm just a little old lady; don't try to dazzle me with jargon!"
    www.hrussman.entadsl.com

  7. #6
    Linux Newbie
    Join Date
    Apr 2005
    Location
    Clinton Township, MI
    Posts
    104

    That can be one point of frustration

    Quote Originally Posted by hazel View Post
    How does this actually work in practice? I have on one or two occasions built from source and had the configure step fail because it couldn't find some library or other that it needed. Obviously that's not a serious problem; you hunt out source code for the library, and build and install that first.

    But do missing dependencies always show up like that? Can a program build and install successfully but then crash because some runtime dependency wasn't met? And, if so, how do you determine what the problem is?
    Not just on Slackware, but on other systems as well, from time to time I have gone to build an application, only to find it requires a variety of libraries as prerequisite code. The best projects clearly state what software is required. If you have a check list in front of you, it makes it a lot easier. You may have everything you need already, you may need a newer version of something, or you may have a bunch of things to get first. It's always easier when those things are known.

    Where a distribution like Debian is handy is that it includes a lot of software and a lot of libraries. Often you won't have to go searching for the source code unless you want to build from source - and it actually has source code repositories available for times that you want to build from source. But it has a different philosophy than Slackware. A Debian fan won't want to run Slackware and vice versa because of those differences.
    Brian Masinick
    masinick AT yahoo DOT com

  8. #7
    Linux Engineer Freston's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    1,049
    Quote Originally Posted by hazel
    How does this actually work in practice? I have on one or two occasions built from source and had the configure step fail because it couldn't find some library or other that it needed. Obviously that's not a serious problem; you hunt out source code for the library, and build and install that first.

    But do missing dependencies always show up like that? Can a program build and install successfully but then crash because some runtime dependency wasn't met? And, if so, how do you determine what the problem is?
    I haven't had that experience ever. I mean, the configure step may fail but it seems pretty conclusive that when the configure step succeeds that the build will succeed.

    Quote Originally Posted by Idris
    The only thing that really puts me off is the dependency resolution. Slackware is a distribution that believes dependencies are the work of the user which I find a strange notion.
    This isn't really true. Slackware users are, per definition, very lazy. It's not called 'slack'-ware for nothing

    But lazy people like reliable machines. And that is the basis of the design of Slackware. The machine should be reliable, because you don't want to clean up mess that the machine made.


    I've had a couple of experiences on a more automated system that my carefully handwritten config files got overwritten during an update. Au!

    Also, if you would like to install snort or openvpn or so on a distro like CentOS 5.5 then you'll find you cannot update certain libraries to the version needed by these programs. So you will have to device a way of updating these manually, thereby breaking several distro's mechanisms and perhaps more than you bargained for unless you really know what you're doing.

    You see? It's all well and good (and incredibly convenient) to have a distro with a repo and build in dependency resolution.... until you find you have to do something outside the scope of that distro. Then these things become obstacles to overcome.

    With Slack, it's much easier. You always follow the same steps. You don't have to fight certain distro-specific mechanisms in order to get it to do what you want. It just all feels much more native, doing things like having several versions of the same library on the system and things like that.

    If there was a way to *dependably* automate this with repo's and dependency resolution and all, certainly that would be most welcome!!!

    But truth of the matter is, that all systems, be they apt or yum or what have you... they all have upsides and downsides. And Slackware, in this respect is more flexible at the (perhaps huge) cost of a more complex install mechanism.


    In practise though, nine out of ten packages can be installed with the simple:
    Code:
    ./configure&&make&&make install&&echo "Hurray!"
    Can't tell an OS by it's GUI

  9. #8
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,279
    Quote Originally Posted by Freston View Post
    It just all feels much more native, doing things like having several versions of the same library on the system and things like that.
    Ah, I wondered how that was handled. If you look at the Debian developer news, you see that it quite often happens that program A can't be released because it needs version 2.3 of libxyz but programs B & C, which are already in the repo, also use libxyz but only work with version 2.1. It took quite a long time for LibreOffice to move from Unstable to Testing for that reason.

    What happens if you have two versions of a library? How does gcc know which one to link against? Just curious.
    "I'm just a little old lady; don't try to dazzle me with jargon!"
    www.hrussman.entadsl.com

  10. #9
    Linux Engineer Freston's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    1,049
    I must confess, I prefix=/path/to/dir while installing libraries, but I never had any trouble with software picking up on this.

    It's all in the makepkg? Because all I said above, it was a lie

    The 'real' sequence of installing packages in Slackware is different.

    Code:
    mkdir -p /home/$USER/build/usr/local/lib/package-version
    ./configure prefix=/home$USER/build/usr/local library-prefix=/home$USER/build/usr/local/lib/package-version&&make
    su;makepkg packagename.tgz&&installkpg packagename.tgz
    But any slacker will know what I mean

    But you really have to read the readme, install notes and ./configure --help before you can do all this and use all necessary configure options correctly because they state what's looked for where.. and indeed often you lack proper info and have to resort to trial and error. Adjusting the makefiles manually and such. These are the cases where you say "I dunno, it all depends, I'd have to have a look..."
    If you know the basics then often you'd be fine. And sometimes it's a mess. Depends on upstream rather than distro. Same with support. Running ZFS on Slackware; support from upstream was a blessing (favourable mention was rightly deserved) but other things I've failed miserably in.

    What I say, our flexibility is a mixed blessing at best. It adds complexity. And sometimes I think the only reason it's more easy to compile against non-standard libraries is because we're used to that.

    What I like best though, is that when upstream says it's a default then it's a default. No distro patching my default values... even if they are more sane. I just like it when I can clearly and easily use upstream documentation to define my values without anything overruling me or giving unexpected behaviour. For example: everyone knows you should disable root ssh logins, but not before I configure privileged accounts on a headless machine. I'll do that manually thank you very much.
    Can't tell an OS by it's GUI

  11. #10
    Just Joined! ford's Avatar
    Join Date
    Jan 2011
    Location
    GA, USA
    Posts
    25
    There are several reasons why automatic dependency resolution is awful. First, with automagic dependency resolution you cannot compile without an optional dependency. You are stuck with it even when you do not want it. Second, what happens if there were a security flaw in a package foo version 1.1 which was required by package bar, but not in version 1.0 that would solve the dependency just as well? Whoops. You're screwed. With Slackware, you get a ton of commonly required libs and such so the majority of deps are never a problem. When you want a package, check SlackBuilds first. They will list dependency requirements, give ya the source and a build script. No problem. You get the choice. You get the power.

    The other thing that I get with Slackware and do not get anywhere else is a system whose configuration is completely based on text files. This means that I can install Slackware to a disk, edit those config files before booting, and have a copy of the entire disc ready for replication on multiple discs for enterprise deployments. Slackware also enables me to follow standard documentation because no configurations are altered by the distribution provider. Slackware just seems to be the most "friendly" even if not "user friendly" distribution I have ever used. For over 12 years now, I have happily Slacked. I have tried tons of distributions... but none of them ever came close to touching the ease of administration of Slackware.

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •