LinuxQuestions.org
Visit Jeremy's Blog.
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-24-2009, 02:43 PM   #16
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,223

Rep: Reputation: Disabled

Quote:
Originally Posted by gnashley View Post
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?
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
 
Old 05-24-2009, 03:08 PM   #17
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,751

Rep: Reputation: 462Reputation: 462Reputation: 462Reputation: 462Reputation: 462
Ah, thanks, I forgot to ask about the *.meta files which are used by others.
Big congrats Eric... and my sympathies, too.
 
Old 05-24-2009, 04:27 PM   #18
gargamel
Senior Member
 
Registered: May 2003
Distribution: Slackware, SLAX, OpenSuSE
Posts: 1,594

Rep: Reputation: 142Reputation: 142
Quote:
Originally Posted by JosephS View Post
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?
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
 
Old 05-25-2009, 05:12 AM   #19
dst
LQ Newbie
 
Registered: Dec 2008
Posts: 2

Rep: Reputation: 0
Quote:
Originally Posted by lumak View Post
SLKCFLAGS="$SLKCFLAGS -march i686 -mtune i686"
There is no need for -mtune here, -march i686 will tune it.



Quote:
Originally Posted by lumak View Post
This will dump all the needed libs of your chosen binary
Code:
objdump -x $1 | grep NEEDED
No, this is not right (same for ldd)
You can try it with wine for example.

Code:
$ objdump -x /usr/bin/wine | grep NEEDED
  NEEDED      libwine.so.1
  NEEDED      libpthread.so.0
  NEEDED      libc.so.6
$ objdump -x /usr/bin/wineserver | grep NEEDED
  NEEDED      libwine.so.1
  NEEDED      libc.so.6
$ objdump -x /usr/lib/libwine.so.1 | grep NEEDED
  NEEDED      libdl.so.2
  NEEDED      libc.so.6
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...)
 
Old 05-25-2009, 11:55 AM   #20
theapodan
LQ Newbie
 
Registered: Jun 2002
Distribution: Slackware
Posts: 19

Rep: Reputation: 0
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.
 
Old 05-25-2009, 12:34 PM   #21
gargamel
Senior Member
 
Registered: May 2003
Distribution: Slackware, SLAX, OpenSuSE
Posts: 1,594

Rep: Reputation: 142Reputation: 142
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
 
Old 06-01-2009, 06:19 PM   #22
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Rep: Reputation: 34
Playing the slots...

Quote:
Originally Posted by samac View Post
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 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
 
Old 06-01-2009, 06:37 PM   #23
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Rep: Reputation: 34
Quote:
Originally Posted by gargamel View Post
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
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
 
Old 06-02-2009, 02:48 AM   #24
Dinithion
Member
 
Registered: Oct 2007
Location: Norway
Distribution: Slackware 13.37
Posts: 436

Rep: Reputation: 56
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.
 
Old 06-02-2009, 01:28 PM   #25
saulgoode
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 227

Rep: Reputation: 90
Quote:
Originally Posted by Shingoshi View Post
Is there anything else which has a better reputation than Arch's Pacman?
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).

Last edited by saulgoode; 06-02-2009 at 01:30 PM.
 
Old 06-02-2009, 02:08 PM   #26
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,612

Rep: Reputation: 1414Reputation: 1414Reputation: 1414Reputation: 1414Reputation: 1414Reputation: 1414Reputation: 1414Reputation: 1414Reputation: 1414Reputation: 1414
Quote:
Originally Posted by saulgoode View Post
Yes, the 'saulgoode' package manager has just such a reputation.
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.

Last edited by dugan; 06-02-2009 at 02:34 PM.
 
Old 06-02-2009, 07:47 PM   #27
theapodan
LQ Newbie
 
Registered: Jun 2002
Distribution: Slackware
Posts: 19

Rep: Reputation: 0
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.
 
Old 06-02-2009, 08:07 PM   #28
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Rep: Reputation: 34
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
 
Old 06-03-2009, 04:52 PM   #29
BrZ
Member
 
Registered: Apr 2009
Distribution: Slackware
Posts: 492

Rep: Reputation: 80
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...
 
Old 06-03-2009, 07:07 PM   #30
gargamel
Senior Member
 
Registered: May 2003
Distribution: Slackware, SLAX, OpenSuSE
Posts: 1,594

Rep: Reputation: 142Reputation: 142
Quote:
Originally Posted by dugan View Post
[...]

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.

[...]

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.

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


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 08:15 PM
Slackware 10: Failed Dependencies Russb Linux - Newbie 9 07-16-2004 09:35 PM
slackware dependencies lenucks Slackware 3 06-22-2004 05:48 PM
Where are dependencies in Slackware packages? sbassi Slackware 2 01-15-2004 04:24 PM
slackware dependencies ??? Krix Slackware 14 10-09-2003 11:14 PM


All times are GMT -5. The time now is 10:04 PM.

Main Menu
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