LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 05-19-2009, 07:51 PM   #1
JosephS
Member
 
Registered: Jun 2007
Distribution: Debian Squeeze, CrunchBang Waldorf
Posts: 517

Rep: Reputation: 38
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?
 
Old 05-19-2009, 09:10 PM   #2
zbreaker
Member
 
Registered: Dec 2008
Location: New York
Distribution: Slack -current, #!, vsido
Posts: 230

Rep: Reputation: 29
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
 
Old 05-20-2009, 03:12 AM   #3
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware [64]X{.0|.1|.2|-current} ::X>=12<=14, FreeBSD_10{.0|.1}
Posts: 2,188

Rep: Reputation: 862Reputation: 862Reputation: 862Reputation: 862Reputation: 862Reputation: 862Reputation: 862
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.

Last edited by astrogeek; 05-20-2009 at 04:17 AM.
 
Old 05-20-2009, 10:48 PM   #4
lumak
Member
 
Registered: Aug 2008
Location: Phoenix
Distribution: Arch
Posts: 799
Blog Entries: 32

Rep: Reputation: 109Reputation: 109
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....
 
Old 05-22-2009, 03:54 PM   #5
BCarey
Senior Member
 
Registered: Oct 2005
Location: New Mexico
Distribution: Slackware
Posts: 1,490

Rep: Reputation: Disabled
Quote:
Originally Posted by lumak View Post
http://www.sbopkg.org/
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.
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
 
Old 05-22-2009, 04:01 PM   #6
lumak
Member
 
Registered: Aug 2008
Location: Phoenix
Distribution: Arch
Posts: 799
Blog Entries: 32

Rep: Reputation: 109Reputation: 109
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
 
Old 05-22-2009, 06:27 PM   #7
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
Quote:
Originally Posted by lumak View Post
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.
 
Old 05-22-2009, 06:47 PM   #8
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Linux Mint 17.1
Posts: 1,424

Rep: Reputation: 137Reputation: 137
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

Last edited by samac; 05-22-2009 at 06:50 PM.
 
Old 05-23-2009, 05:35 AM   #9
suid0
Member
 
Registered: Jul 2005
Location: Brazil
Distribution: Slackware, openSuSe, Ubuntu, Fedora
Posts: 56

Rep: Reputation: 16
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...
 
Old 05-24-2009, 01:25 PM   #10
chess
Member
 
Registered: Mar 2002
Location: 127.0.0.1
Distribution: Slackware, OpenBSD, FreeBSD
Posts: 728

Rep: Reputation: 168Reputation: 168
Quote:
Originally Posted by T3slider View Post
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.
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}

Last edited by chess; 05-24-2009 at 02:28 PM.
 
Old 05-24-2009, 02:12 PM   #11
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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.
 
Old 05-24-2009, 02:28 PM   #12
lumak
Member
 
Registered: Aug 2008
Location: Phoenix
Distribution: Arch
Posts: 799
Blog Entries: 32

Rep: Reputation: 109Reputation: 109
@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
Code:
objdump -x $1 | grep NEEDED
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...

Last edited by lumak; 05-24-2009 at 02:33 PM.
 
Old 05-24-2009, 02:34 PM   #13
chess
Member
 
Registered: Mar 2002
Location: 127.0.0.1
Distribution: Slackware, OpenBSD, FreeBSD
Posts: 728

Rep: Reputation: 168Reputation: 168
Quote:
Originally Posted by lumak View Post
@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"
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.

Last edited by chess; 05-24-2009 at 02:38 PM.
 
Old 05-24-2009, 02:42 PM   #14
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,393

Rep: Reputation: Disabled
Quote:
Originally Posted by gnashley View Post
I find it very interesting that (at least some) of the packages for slackware64 are using slack-required files. Hmmm...
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
 
Old 05-24-2009, 03:04 PM   #15
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware Question on Dependencies OPP Slackware 6 05-22-2006 09:15 PM
Slackware 10: Failed Dependencies Russb Linux - Newbie 9 07-16-2004 10:35 PM
slackware dependencies lenucks Slackware 3 06-22-2004 06:48 PM
Where are dependencies in Slackware packages? sbassi Slackware 2 01-15-2004 05:24 PM
slackware dependencies ??? Krix Slackware 14 10-10-2003 12:14 AM


All times are GMT -5. The time now is 10:53 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration