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

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...