[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: More strange F9 dependencies



On Fri, 21 Nov 2008 08:43:38 +1030, Tim wrote:

> > Run: repoquery --whatrequires libbluetooth.so.2
> > 
> > That shows all packages with a _direct_ dependency on that library.
> > Nautilus depends on something that depends on bluez-libs.
> 
> It strikes me that with things like this, and others (e.g. requiring
> CUPs on a single, headless, remote web server), that we should be
> developing some strategies to remove *USELESS* dependencies.  Even if
> that means an extra "hack" repo with various dummy RPMs to satisfy RPM
> demands for files that will never be used, or to supply the bare minimum
> files it wants for a dependency, without the rest of the package.

RPM dependencies are no silly game.

Especially not the automatically determined dependencies on shared library
names. They are not hand-crafted by a packager.

If a program or library is built and linked with some other library, in
the majority of cases this leads to a strict dependency: you must
install the _required_ (!) library, or else the program fails and
doesn't start since the system's linker stumbles upon a missing library.

You cannot simply insert a dummy package, which provides a virtual
"libfoo.so.1" but which does not include the needed shared library
and its interface.

This is different only with optional plugins, which can be added or
removed freely, and which are stored in optional packages to make
dependencies optional. Or with libraries that can be loaded by an
application itself (at run-time) and need not be present. It requires
extra efforts at the implementation-level to decouple a library
interface, so it can become optional at run-time. In many cases
the extra effort is not worthwhile.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]