Slackware and dependencies
 

I have been using slackware for a couple of years now. I like the distro.
I would like to know what the problem is with a package manager that
Resolves dependencies? I’ve heard some negativity about this. I don’t see
Why this would be a problem. What is the difference if a
person downloads and installs dependencies or a program does it?

One of the fundamental principles of Slackware is user control...not reliance on a gui or cli curtained means of proper package management. It is what separates this distro from many...again a matter of choice as is all of GNU/Linux. I admit, when I first tried Slack it was one of my worrying points...as in "God..I can't be keeping track of all this stuff"..but in reality it proved to be all so simple. I guess it will remain a basic precept of Slackware..which is a good thing imho :)

There are advantages...
 

I used Mandrake/Mandriva for several years and really liked URPMI. I always manage my systems from a terminal instead of the GUI tools anyway, and URPMI served me well. Although a recurring question was 'if I want the latest programX.1.2.3.4, where will I get a package?'. For the ones I relied on I would build them myself - and dependencies when necessary, rather than be tied to someone else's package availability.

But with Slackware, I basically have ALL my packages and dependencies under my own control, and when I need programX.1.2.3.4 I build if from an SBo package script, or write my own. So I am still building it as I was for many apps under Mandriva, but now I am building it WITHIN the system framework instead of outside it! That is actually an improvement!

The reality is that unless you really just can't be bothered about the state of your systems, managing your Slack packages and their dependencies is just not a difficulty.

http://www.sbopkg.org/

SBOPKG works wonders... It doesn't exactly handle dependencies, but it's the next best thing. It works with a local file structure downloaded directly from slackbuilds.org to your computer to set up a build order to install your software more efficiently. On the question of dependencies, it would actually have to be documented in the package it self. Neither Slackware nor slackbuilds.org does this in a standard manor. So in essence, the problem is not in the package manager but in the package format ;). I will say this. It helped wonders installing gnucash... of which I'm a bit disappointed in my self because I polluted my system with gconf....

All dependencies for packages on slackbuilds.org are noted in the READMEs and, in my experience, the dependencies are always available on the same site.
Brian

Indeed. However it is not displayed in a formatted manor that any sane parsing method could reliably pick up on. Hence, they need a separate dependencies file to note such things... or even including an extra few lines into the .info files would work....

Something as simple as this would work on at least slackbuild's end.

DEP1="pkgname-version"
DEP2="pkgnmae-version"


It would preferably need to be a file that goes into the install/ directory in the package that would be part of the files on slackbuilds.org as well as something to go into /usr/doc/pkgname-version OR better yet in the package's description file in /var/adm/package/pkgname-version-arch-1

The problem with this approach lies with the optional dependencies. They would probably have to have an "OPTDEP1" option, for example, to denote dependencies that can be used but are not necessary. Any of the audio or video applications have tons of these (some, like exotic codecs, not even noted). I have no affiliation with slackbuilds.org, but I would assume they're steering clear of this approach to prevent automated tools from trying to automate dependency building. It probably could be done well (unlike many of the actual dependency-resolving distros out there that just throw in the kitchen sink) by allowing you to select or deselect optional dependencies if the above format for dependency-disclosure was adopted, but that just introduces possible problems.

I don't know where I stand on the issue of automating slackbuilds.org builds, but I believe Chess has said in the past he has no plans to do any such thing (and for good reason), and frankly, I'm happy with sbopkg as it is now.

I used to use Debian many years ago, and more than once a package called for an update to glibc. Being young and fresh faced at the time I let the machine get on with it, after all it knew what dependencies it needed. Unfortunately other programs needed the old glibc, so I tried to downgrade, but the machine wouldn't let me because package B needed the new version. I resorted to a force and .... system borked.

I moved to Slackware. No system failures that have not been caused by me in over five years.

That is why Slackware users like to have a package system that lets them have control. Dependency checking puts you in the hands of someone who might not know as much as you, and certainly doesn't know your system.

samac

I tried to use many other distros but I always get into trouble because of dependencies. Slackware was the first distro I tried (since 96) and I still can't think about switching to another distro. The way Slackware deal with packages seems good enough. Simple, fast...

Sbopkg will never check dependencies if that's what you mean.

BTW, sbopkg will have full support for Slackware64 and the SBo scripts that have been updated for Slackware64. I am running sbopkg on Slackware64 now and it works great. The only change that must manually be made (until a new sbopkg release) is to export ARCH in the sbopkg.conf file, just like TMP and OUTPUT are exported like so:

export ARCH=${ARCH:-x86_64}

My src2pkg program can produce slack-required files which look like this:

# wmaker-0.92.1afx1
# Requires: |Supplied by:
# File: libX11.so.6.2 |: x11
# File: libXext.so.6.4 |: x11
# File: libXft.so.2.1.2 |: x11
# File: libXpm.so.4.11 |: x11
# File: libXrender.so.1.2.2 |: x11
# File: libexpat.so.0.5.0 |: expat | aaa_elflibs
# File: libfontconfig.so.1.0.4 |: fontconfig
# File: libfreetype.so.6.3.7 |: freetype | aaa_elflibs
# File: libjpeg.so.62.0.0 |: libjpeg | aaa_elflibs
# File: libpng.so.3.1.2.12 |: libpng | aaa_elflibs
# File: libtiff.so.3.8.2 |: libtiff | aaa_elflibs
# File: libungif.so.4.1.4 |: libungif
# File: libz.so.1.2.3 |: zlib | aaa_elflibs
expat | aaa_elflibs
fontconfig
freetype | aaa_elflibs
libjpeg | aaa_elflibs
libpng | aaa_elflibs
libtiff | aaa_elflibs
libungif
x11
zlib | aaa_elflibs

These are compatible for use with slapt-get(the uncommented lines), at least. But I add more explicit info above as human-readable or parsable info.

src2pkg also produces slack-provides files. These are not used by any current package managers, but they provide a quick way to identify any static or shared libs, libtool *.la files and links to libs, without having to parse both the package database file and the doinst.sh for the package. They make nice reading on a Sunday afternoon... Because of the way they are named, they can be included in packages and will be ignored and removed by the installpkg when the package is installed.

# wmaker-0.92.1afx1 Provides these libraries and links to them:
usr/lib/libExtraWINGs.a
usr/lib/libExtraWINGs.la
usr/lib/libExtraWINGs.so
usr/lib/libExtraWINGs.so.0
usr/lib/libExtraWINGs.so.0.0.0
usr/lib/libWINGs.a
usr/lib/libWINGs.la
usr/lib/libWINGs.so
usr/lib/libWINGs.so.2
usr/lib/libWINGs.so.2.0.1
usr/lib/libWMaker.a
usr/lib/libWMaker.la
usr/lib/libWMaker.so
usr/lib/libWMaker.so.1
usr/lib/libWMaker.so.1.0.1
usr/lib/libWUtil.a
usr/lib/libWUtil.la
usr/lib/libWUtil.so
usr/lib/libWUtil.so.1
usr/lib/libWUtil.so.1.0.2
usr/lib/libwraster.a
usr/lib/libwraster.la
usr/lib/libwraster.so
usr/lib/libwraster.so.3
usr/lib/libwraster.so.3.1.0


I find it very interesting that (at least some) of the packages for slackware64 are using slack-required files. Hmmm...

I don't care for bloody wars over package *handling*, but I find that a little extra info about a package is nice to have around -if only for myself. Since I have builds for more than 1500 programs, I try to make things easier for me to remember and re-create builds.

@chess
I would NOT recommend this method at all for slackware64 until SBo has an actual slackware64 tree. This means they tested and certified it for slackware64. Until this point, I have assumed slackware64 would be purelib with all 64 bit libs in /lib. Some of these scripts make this assumption too.

Not that you will break your slackware64 system... but you will end up with 64 bit libs in your 32bit directory.

You need to typically add the following to the architecture x86_64 check:
LIBSUFFIX=64

then add the following to the compile stage:
--libdir=/usr/lib$LIBSUFFIX

There are also other minor things that may need to be fixed... for example... you may need to specify -m32 or -m64 in the $SLKCFLAGS. Which leads me to believe that maybe the $SLKCFLAGS definition should actually be for example...:
SLKCFLAGS="$SLKCFLAGS -march i686 -mtune i686"



@gnashley
This will dump all the needed libs of your chosen binary ;)
I'm sure you could make that really complicated then search your /var/adm/packages/ for what files they are in then build a new file containing what was and wasn't found... HOWEVER, this is all after the fact of building the actual package...

Yes, sbopkg will only officially support it when SlackBuilds.org supports it. The scripts are being updated for Slackware64 in the SlackBuilds.org tree in preparation for the 13.0 release. The SlackBuilds.org template has been updated to address the SLKCFLAGS and LIBDIRSUFFIX.

Yeah... that occurred because initially, all those new packages in ./extra were not meant to be added to slackware64 at all. They were for our internal play-testing of slackware64. There were many more that I built but were removed before going public, and I have uploaded those into my own repository.

Those "slack-required" references should have been erased from the packages & SlackBuilds first, but they were overlooked.
Do not read in their presence that Slackware will be supporting slack-required files! Those are my own additions (for my own repository) and I expect they will be removed from those two packages.

Eric

Alien Bob:
Oh, I didn't really think that the slack-required files were going to become 'mainstream' Slackware, but I wondered how they got there. Does slackpkg use them as well as slapt-get?

lumak, src2pkg is supposed to generate the info for use later, from the finished package -so that the file accurately represents the dependencies of the built package. A qiuck look at the file next time gives me a head up if I rebuild it. Including the file in the package and making it compatible with any package managing software is a favor to those who like to use them and do not enjoy compiling software themselves or working out the build/install order. Their dependency 'hell' is my heaven... actually, the other way around -I go through hell for them so they can enjoy heaven, if they like it...

No, these files have no support in Slackware. I was asked several years ago - I think by the GoblinX team - to add metadata stuff to my package repository so that they could use it directly in their distro as an installation source.

Erif

Ah, thanks, I forgot to ask about the *.meta files which are used by others.
Big congrats Eric... and my sympathies, too.

The main difference is that the person knows what the person needs, while the program doesn't.

Some of the problems caused by automated dependency resolving have already been described, such as problems with downgrades, or when two packages define different dependencies.

Another problem is that dependencies are defined by package maintainers with different needs and differing levels of experience and skills. So if you download a package, such as kmyoney2, it depends on the maintainer, if it is compiled with support for OFX and HBCI, only one or none of these. And depending on what the maintainer needs for his daily use case, this causes different dependencies. For HBCI and OFX you need to have some libraries in your system, otherwise kmymoney2 can't be used for online banking.
On the other hand: The program will run properly as a personal finance tool without support for online banking. But if the package was defined with HBCI dependencies you won't be able to install it, at all, even if you don't need HBCI, when you use a package manager like RPM.

Also, dependencies can be deep. If you are going to install a package like Gnucash on Slackware, you better are prepared for having a relevant portion of the Gnome desktop environment on your system. Or maybe you got your Gnucash package from a different package maintainer, who preferred not to define as many dependencis. Then Gnucash may not start or run properly in your system.

Then, package dependencies may conflict. For example, you may want to use Gnucash and kmymoney2 in versions that require different versions of HBCI and OFX related libraries. Who wins?

In the end, the human being in front of the screen, is the only one who knows what is right. I am speaking of YOU.

But I have to say, that defining a minimum set of real requirements, i. e. packages that are really required in the sense, that a program won't run, at all, without them, could be helpful. But sophisticated concepts like RPM actually are less helpful than expected, in practice. It all depends on the skills and experience of the package maintainers. If they are doing their job well, and if they anticipate what other users might need, then it works quite well. But the effort to do it right by far weighs out the benefits, and sooner or later you WILL rund into a situation where packages are conflicting, or where Gnome is filling up your harddisc when all you wanted is Gkrellm.

I have used SuSE Linux a lot, and this distro has shown me many times, how helpful dependency resolving package management can be, but also sometimes, what problems it can cause. But initially I asked the same questions like you. Being used to the comfort of YaST and RPM, I almost couldn't believe that a distro without all this could survive, at all. But after several years of using both SuSE/openSUSE and Slackware in parallel, my conclusion is, that despite sophisticated and comfortable tools such as YaST (some hate it, I still love it) the maintenance and the package management of Slackware are much more efficient, and that is even easier, not more difficult, to keep my system clean and consistent, when I do not rely on some program.

Howevever, I use tools like slapt-get, occasionally, to check for unsatisfied dependencies, but not for automated installation of supposedly missing or outdated stuff. Then I check the output of this program, and decide what I do (usually nothing).

However, I have to say, that I like the way the guys at slacky.eu work, and I do like their little tool slackyd. Their approach is very sensible, in my opinion, as they simply usually don't overdo. When there is an update for one of the stock Slackware packages, this little script clearly states, if the update package stems from Slacky.eu or is an official one. However, their Kaffeine package defines a dependency for lame, but you only need that for watching DVD movies, but not to watch TV with the DVB-T functionality of Kaffeine, as far as I can tell. So if all you want Kaffeine to use for is watching TV, this is an unnecessary dependency for you.

You get it?


gargamel

There is no need for -mtune here, -march i686 will tune it.



No, this is not right (same for ldd)
You can try it with wine for example.

When you see libdl.so you can be sure that this is not the right way to resolve dependencies.

Wine for sure uses many more libraries than just this few.
Here http://wiki.winehq.org/Recommended_Packages you can see that wine needs a lot of libraries (x11, libpng, libjpeg, freetype, fontconfig...)

I've never had any problems with Slackware.

However, I find the lack of a package manager that lacks dependency resolving to be a real turnoff. Software seems to have become more diffuse than when I installed in that more of the software is in libraries, and as a result, compiling/installing individual libraries has become burdensome to the point that I'd be willing to sacrifice some control for some sanity when installing things like Gnucash. And hard drive space isn't so precious now that I'd want to avoid installing extraneous packages.

I've been thinking about installing Arch, probably as a dual boot option.

If you really want dependency resolving package management, you might want to look at either slackyd from slacky.eu, which works well and gives you full control at the same time, or maybe the smart package manager, which is said to be good too, and to my knowledge pretty much distro independent (as much as a package manager can be, that is...), but I haven't tried it myself.

Of course, Arch's Pacman enjoys excellent reputation.

gargamel

Playing the slots...
 

I don't know if anyone else has mentioned this or not. But the dependencies of older packages could easily be resolved by using a technique like Gentoo's. Gentoo has what's called slots. And slotted packages can exist on the system in more than one version. The same I believe is true for glibc.

Shingoshi

At what point is excellent not perfect? If Arch's Pacman has an excellent reputation, why can't it be used as a starting point for the development of something for Slackware? Is there anything else which has a better reputation than Arch's Pacman?

Shingoshi

Shingoshi:

What I don't get, is why are you still using slackware? You are obviously not happy with it. If you prefer Arch/Gentoo, then use them! Stop trying to change slackware. WE like slackware the way it is. And by the way, if something is missing, you make it. If you can't do any programing, hire someone to do it for you. If you don't want to pay, stop whining.

Yes, the 'saulgoode' package manager has just such a reputation. At least amongst users of my systems, which is what matters to them (i.e., me).

That would be the SPaM package manager?

Seriously, though...

One advantage of not tracking (or rather, automatically downloading) dependencies is that it makes unofficial repositories such as SlackBuilds.org and slacky.eu safer to use. With most other package managers, you'll find yourself manually editing pinning settings to manage your unofficial repositories, and you'll still run into trouble when two repositories start offering the same package.

It also makes managing individual packages easier. With Slackware, I can replace a package with one from -current and think nothing of it. If I do that on Debian (or a Debian-based distro), that package will probably get reverted with the next apt-get upgrade. If I pin that package, then apt-get upgrade won't revert it---but won't upgrade its dependencies either.

Furthermore, it's not true that Slackware has no dependency-tracking package downloaders. Several (including slapt-get) have already been mentioned. And Slackware used to include swaret.

Yes, installing a lot of dependencies for a package can be labor-intensive. However, most packages with a lot of dependencies are GNOME packages. I usually deal with that by installing GNOME right after I install Slackware.

Since writing my 5/25 post, I have installed Arch.

Pacman is great. Installing recent versions of software is a breeze. The AUR is nice.

However -- I seem to be running into more issues with configuration than I ever have had with slackware. On the other hand, working out the configuration is easier and faster than laboriously searching for obscure libraries that only exist on someone's basement server (hyperbole).

I think that the tools that do the dependency resolving for slackware, like swaret (which I used for a while) are a kludge, and maybe lack the refinement (or certainly reliability with swaret) of pacman.

On the other hand, I am typing this in Slackware, which tells you that thus far I haven't spent the time to get everything working in Arch. The default install in Slackware truly does "just work," at least more so than Arch.

Which will win out on my system? I dunno.

I guess what I'm really looking for, is a way to know precisely what was used to create/test the source that has been distributed. I've built so many packages that sometimes have you hunting in that proverbial basement repository. It would be nice to find a list of dependencies in the foyer instead.

Shingoshi

When proper setup, the defaults are really good. Basically look for the error on compiling the desired app and the missing requested lib and read as much as you can...

swaret isn't actively developed/maintained, it seems. Didn't know that it was included with Slackware in the past. Since I use Slack, it was not (around v10.something).

slapt-get is also a very useful program. It has an option to prevent official Slackware packages being updated with 3rd pary packages. Slackware packages will be updated only with Slackware patches, instead of being replaced by a more current 3rd party package. At the same time it is possible to upgrade 3rd-party stuff with 3rd party packages.
Initially this seemed to work quite well. However, then I tried to upgrade a 3rd-party package. The new package version defined dependencies of other 3rd-party packages that would replace Slackware packages. And as some of the defined dependencies defined other deps, I found myself down in dependency hell.

As I said, slapt-get is a very useful tool, just use it with care.

gargamel

Hello from Australia,

I have been using gnu-linux for a few years - ubuntu, then wolvix as a workstation etc.
I recently changed to slackeare12.2 as my workstation and have learnt far more in the last 2 months than the previous 2 years. I have now loaded slackware64-current also for educational purposes.

To load extra applications I have been downloading .tgz binaries and used installpkg and this has worked great on 12.2 stable as if you need a dependency you are told in the terminal. However in slackware64, it tells me the package is not found (orphan pkgs load fine).
My question is, how can I can tell what the dependencies are needed by my system?
Can I type a command to ask what is required for the particular package?

I am not sure if I am ready to learn compiling from tar.g, however I do prefer to stick with the slackpkg system instead of a Gui.

Not in answer to #31, but rather continuing the discussion previous. I, at least for my purposes neither have need nor want for an automated "apt-get" functionality in Slackware. Before coming over to this distro I was strictly a Debian based devotee...for good reason. However the freedom of the Slackware package management system (the individual coupled with "slackpkg" for official programs or "sbopkg" for SlackBuilds ) in addition to the fact that the full install gives one everything but the kitchen sink takes care of many average users needs. Again, some might require more...but for me, I've finally reached Linux nirvana:)

@vigi - you are running a rolling development release there so any packages apart from the ones in the current tree are deemed to change and loose dependencies. You really should only run packages from the current tree with current. If you wish to run something additional you will have to build it yourself from source. Even then - as the outside libraries change - you will have to rebuild it !

Honestly - current isn't like stable and different rules apply !
Nope - however packages in the current tree will be updated in sync so will be OK. However, as mentioned, external packages may need rebuilding.
Again - you will have to get used to building your own packages if you want to run external packages with current.

thank you dgetty,

I have tried so many distros from ubuntu to the bsds, and I have found myself progressively going to the original systems after getting tired of the fluffy Gui's hiding important information. I am very happy with slackware12.2 as my workstation, so I will continue and see if I can build packages for it initially.

Personnaly, i've given up on automatic dependencies management the day that, after installing a small, KDE-based debian and wanting to install Cups to print easily, apt-get downloaded me the full Gnome install just because there was a small dependency of the Cups package on gnome-print.
That and the amount of dependencies-managing systems I borked.
And with the fact I like to compile my own stuff and this is definitely not good with a dependecies-managed package system.
With Slack, I just make a full install which is still light compared to other distros, and then compile what I need.
And upgrades work so well I have not reinstalled my systems for 5 years, moving from a version to another, then running definitely current, until my disk failed. :-)
Slack is just exactly what I want as it is.

Look at this one:
http://www.linuxquestions.org/blog/g...lackware-1990/

I thought it only fair that I thank you here as well...
 

You can read my full thanks at the link above.

Shingoshi

Thank you very much-I will try this script.

I also do not want an auto slaptget or gsplapt system,that forever updates and sometimes creates problems.
What I want in a system is a fully functional stable base distro (preferable without the annoying extras in KDE), that can be customized to my taste with some select applications manually.

This way when it breaks, I know who to blame (me).

The way I understand slackware (please correct me if I am wrong) I can keep the original system up to date with <slackpkg> from a mirror, and anything I install manually with <installpkg> is held separately.

I believe I have found the right distro (like Buddha after searching everywhere else it was under my nose) in slackware. Each distro I have tried appears to build a glossy front and add a package manager to make life a little easier-however more often than not the gui,s do not work until you have configured the system.

I am now much preferring to learn to do things manually through the terminal, as when it does not work it generally gives you feedback to solve the problem.

thanks again for the help.

Well said - spoken like a true Slacker ;)

The best dependency tracking mechanism is you - check documentation and observe when building. Beware of automated tools - they can fail. A good root round this forum will give you more information.
That's about it. However for this to be in effect - (the installpkg part) - you obviously have to become familiar with creating packages and not just "./configure;./make;./make install". This is itself is a very good habit to keep things manageable. Slackpkg, slackbuilds and Sbopkg all help with system administration.

Good Luck in future !

Slackware "just works" while many others "only just work".