Mailinglist Archive: opensuse (2831 mails)

< Previous Next >
Re: [opensuse] Re: MiniSUSE project page.
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Sun, 23 Jul 2006 00:22:16 +0200
  • Message-id: <44C2A518.3020306@xxxxxxxxx>
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, 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

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

> 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 ( requires symbols from and
If you start amarok and don't have and
installed, the runtime linker ( 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 :\

- --
-o) Pascal Bleser
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
Version: GnuPG v1.4.2 (GNU/Linux)


To unsubscribe, e-mail: opensuse-unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-help@xxxxxxxxxxxx

< Previous Next >
Follow Ups