-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jdd wrote:
Pascal Bleser wrote: ...
hell", but I really don't understand... never, ever install RPMs "manually" (with rpm -i/-U/-F) unless you really know what you are doing. Always use a package manager (yast2, zmd, rug, smart, apt, yum, whatever), as it will nicely resolve the dependencies for you and install everything that's needed.
not right. The package manager know only about the libraries it have into it's own database, not other ones. most app I need to compile rely on the very last library that yast don't know of.
The package manager only knows about the packages that are in its list of repositories, indeed. That's pretty much the only issue with "dependency hell": if installing a package requires another package that's in another repository (e.g. if you install my amarok packages, they require libxine1 from packman). Now, needing the very latest version of a package is a totally different issue, that's not "dependency hell" (or at least not my understanding of it ;)). That's something that we "community packagers" (Packman team, various suser-* repositories on gwdg.de, other in the Build Service, my repository, ...) are trying to address, by providing the very latest version of many libraries and applications. It's not always easy to find the very latest version of some piece of software as a package. Either it's maintained in my repository (or Packman, or a suser-* repo, or in the Build Service, or ...) and you'll most probably find the latest version there, or it's not. It's not much better with other distributions btw. Yes, Debian and Ubuntu have huge repositories where you can find almost anything, but they often don't have the latest version. Source-based distributions (like Gentoo) seem better suited for that at first hand, but then again you have to compile *everything* yourself, and possibly recompile tons of dependencies and other things in order to get that version of a library. The authors of the software usually provide packages for Debian and/or Fedora, rarely for SUSE Linux (unfortunately). But then again, they are usually rather good at writing software but not necessarily very good at packaging and from what I see most of the time, those packages made directly by the authors themselves are not very good, not worth much more than a tarball with configure && make && make install.
When the web page of the app author is well done (for example the kdenlive one), each needed library is exactly listed with the link to it, it's enough to go and take it. but if this is not done, one need to compile (or run rpm, this is sensibly the same), look at the error message and go on.
Mhhh, well, it's not the same. When you build an RPM, rpmbuild automatically scans resulting binaries for dependencies on shared libraries (e.g. libssl.so.0) and script interpreters (e.g. /usr/bin/python). Those automatically discovered dependencies are put (as "Requires") into the resulting RPM package. If you install a package that requires libssl.so.0 and you don't have that library provided by any installed package, RPM will complain and abort the transaction (unless you specified --nodeps, but that's a really bad idea). Package managers (like yast2, rug, smart, apt, ...) will resolve such dependencies (e.g. libssl.so.0 or /usr/bin/python) onto packages and understand that they also have to install e.g. openssl or python. Finding out about dependencies to *build* something from source is a totally different thing, I wasn't referring to that (usually, typical end-users don't do that).
so: use Yast, and thank SUSE for having one of the largest available repository or be prepared to face dependency problems
Well, kindof, you are talking about building something from source, not about resolving dependencies when you install a package ;)
This has been possible since a very long time with YaST2 ;) Those are just .sel files:
there are no more sel files in 10.1 (or none that yast can create)
So, why are there still .sel files here: http://ftp.belnet.be/pub/mirrors/ftp.opensuse.org/opensuse/distribution/SL-1... ? ;)
and I think you miss the point (sorry, probably my fault).
Many developpers makes (or autoconfig) from they own computer. They have on it a bunch of libraries. The tools include in the definition file all the libraries that could ever be used.
Ok, so you really mean some dependency definition for *building* stuff from source, right ? That's the whole point of having packages and RPM .spec files ;) Usually those are not made nor maintained by the authors of the software, unfortunately.
* it's a good idea to have a gnome menu on a kde app? the tool note gnome as needed * there is a gui front end to your console app? the tool makes X and kde needed * I never use ogg, but want mp3, why do amarok install ogg libraries? (because it don't know what I want)
Sounds to me like you should use Gentoo instead of SUSE Linux. But Gentoo has other problems.
all this I _have_ encountered Yast is not at present time sufficiently fine grained to cope with this.
YaST2 has absolutely nothing to do with that. What you are referring to is how the packages are made (the RPM .spec files), not how package managers work. If you don't have a lot of subpackages in the first place, no package manager will be able to be as fine grained in the package selection anyway.
I hope the new package system will be able to know that some dependencies must _not_ be solved for some profile.
Dependencies must *always* be resolved, especially on shared libraries. Let's take your amarok/ogg example. You get an amarok RPM that has been compiled with Ogg/Vorbis support (because almost everyone wants that). That means the amarok binary or one of its own shared libs (libamarok.so.xxx) requires symbols from libogg.so.xxx and libvorbis.so.xxx If you start amarok and don't have libogg.so.xxx and libvorbis.so.xxx installed, the runtime linker (ld.so) will complain about unresolved symbols and will *not* start amarok. That's how it works, and there is no way to circumvent that. For some applications, it's possible to do that though, because they externalize their features/capabilities as plugins (usually shared libraries loaded with dlopen() or libtool/libltdl) and are smart enough to disable features if the corresponding plugin could not be loaded. But that's really the exception, and not the rule. 90-95% of applications don't work that way and burn dependencies into their binaries at compile time (usually depending on what you pass to the ./configure script), not at runtime.
in fact libraries should be split in more catagories: * absolutely necessary to run the app (gcc :-) * mandatory for some functions, but not for others (codecs, desktops)
and I think this will need some work with the packagers. If the build service is as attractive as I feel it will be, the problem will be much simpler.
I'm afraid you are dreaming of something that is not technically feasible :\
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\