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

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