Hi,
While looking through the updates mail, I saw something that sounded intriguing, "hamster-applet." Did a yum info query on it, then thought I'd install it to have a look. But it wanted to drag in a ridiculous number of dependencies, most of them devel packages.
Surely a precompiled non-devel RPM shouldn't be dragging in development packages? That's got to be a major design screw up. Doesn't incorporating a package into a repo involve some sort of checking procedure to reject packages trying to do that sort of nonsense? (Non-devel packages depending on devel packages.)
yum install hamster-applet
...[snip]...
============================================================================= Package Arch Version Repository Size ============================================================================= Installing: hamster-applet i386 0.4-1.fc9 updates 133 k Installing for dependencies: GConf2-devel i386 2.22.0-1.fc9 fedora 103 k ORBit2-devel i386 2.14.12-3.fc9 fedora 187 k alsa-lib-devel i386 1.0.16-3.fc9 fedora 963 k audiofile-devel i386 1:0.2.6-8.fc9 fedora 16 k autoconf noarch 2.61-10.fc9 fedora 800 k automake noarch 1.10.1-2 fedora 532 k dbus-devel i386 1.2.1-1.fc9 fedora 41 k dbus-glib-devel i386 0.74-6.fc9 fedora 40 k docbook-dtds noarch 1.0-35.fc9 fedora 815 k docbook-style-dsssl noarch 1.79-5.fc9 fedora 317 k docbook-style-xsl noarch 1.73.2-9.fc9 fedora 2.9 M docbook-utils noarch 0.6.14-13.fc9 fedora 67 k esound-devel i386 1:0.2.38-7.fc9 fedora 18 k evolution-data-server-devel i386 2.22.1-2.fc9 fedora 276 k evolution-data-server-doc i386 2.22.1-2.fc9 fedora 515 k glib2-devel i386 2.16.3-5.fc9 fedora 1.2 M gnome-python2-evolution i386 2.22.0-2.fc9 fedora 36 k gnome-vfs2-devel i386 2.22.0-1.fc9 fedora 260 k gnutls-devel i386 2.0.4-3.fc9 updates 1.3 M gtk-doc noarch 1.9-4.fc9 fedora 132 k hal-devel i386 0.5.11-1.fc9 updates 32 k imake i386 1.0.2-6.fc9 fedora 313 k indent i386 2.2.10-1.fc9 fedora 116 k libIDL-devel i386 0.8.10-2.fc9 fedora 19 k libbonobo-devel i386 2.22.0-2.fc9 fedora 509 k libgcrypt-devel i386 1.4.0-3 fedora 87 k libgnome-devel i386 2.22.0-3.fc9 fedora 84 k libgpg-error-devel i386 1.6-2 fedora 12 k libsoup-devel i386 2.4.1-1.fc9 fedora 158 k libxml2-devel i386 2.6.32-2.fc9 updates 2.2 M libxslt-devel i386 1.1.24-1.fc9 updates 329 k openjade i386 1.3.2-31.fc9 fedora 986 k opensp i386 1.5.2-7.fc9 fedora 1.1 M perl-SGMLSpm noarch 1.03ii-18.fc9 fedora 25 k popt-devel i386 1.13-3.fc9 fedora 395 k python-sqlite2 i386 1:2.3.3-3.fc9 fedora 82 k sgml-common noarch 0.6.3-23.fc9 fedora 43 k zlib-devel i386 1.2.3-18.fc9 fedora 42 k
Transaction Summary ============================================================================= Install 39 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 17 M Is this ok [y/N]: n Exiting on user Command
Hi,
While looking through the updates mail, I saw something that sounded
intriguing, "hamster-applet." Did a yum info query on it, then thought I'd install it to have a look. But it wanted to drag in a ridiculous number of dependencies, most of them devel packages.
Surely a precompiled non-devel RPM shouldn't be dragging in development
packages? That's got to be a major design screw up. Doesn't
incorporating a package into a repo involve some sort of checking
procedure to reject packages trying to do that sort of nonsense? (Non-devel packages depending on devel packages.)
<snip>
Quite often, those -devel packages have library files included on which the non-devel package depends. Packages that depend on the kernel-devel packages spring to mind, but many others do, as well.
Personally, I'd rather have the appropriate -devel package installed, so that the library dependencies are met, than to have an application litter the system with its own copy of the same libraries.
As an example, see the thread I started yesterday, subject:
"Can't log into KDE on F9, via nx, after recent updates? Error message about kstartupconfig4."
The issue was that the NessusClient application, compiled for Fedora 9, includes a copy of various QT libraries, and the installation process places them in /opt/nessus/lib, places an entry in /etc/ld.so.conf, pointing at that directory, and then runs ldconfig.
Because there were pointers at incompatible QT libraries, the process of logging into KDE4 became non-functional. Commenting out the /opt/nessus/lib line and rerunning ldconfig fixed it for me (thanks to Rex Dieter for helping me get my head back out of my tuchas on that one), but if the NessusClient had relied, instead, on the QT libraries that come with F9 (or had pointed out that I needed to install specific devel packages to make things work), I'd have not run into that situation in the first place.
Mike Burger wrote:
The issue was that the NessusClient application, compiled for Fedora 9, includes a copy of various QT libraries, and the installation process places them in /opt/nessus/lib, places an entry in /etc/ld.so.conf, pointing at that directory, and then runs ldconfig.
Because there were pointers at incompatible QT libraries, the process of logging into KDE4 became non-functional. Commenting out the /opt/nessus/lib line and rerunning ldconfig fixed it for me (thanks to Rex Dieter for helping me get my head back out of my tuchas on that one)
Speaking of that (sorry, thread hijack warning), would you mind letting the folks you got the NessusClient rpm from, that it's breaking peoples f9 systems?
Otherwise, gimme a pointer, and I'll sic my fedora ninja monkeys on them.
-- Rex
On Tue, 2008-06-03 at 09:49 -0400, Mike Burger wrote:
Quite often, those -devel packages have library files included on which the non-devel package depends. Packages that depend on the kernel-devel packages spring to mind, but many others do, as well.
It rather begs the question though: why does a package have a library that the package itself doesn't depend on? e.g. xine-lib-devel includes /usr/lib64/libxine.so but xine itself doesn't. Wierd.
poc
On Tue, 3 Jun 2008 09:49:13 -0400 (EDT), Mike Burger wrote:
Hi,
While looking through the updates mail, I saw something that sounded
intriguing, "hamster-applet." Did a yum info query on it, then thought I'd install it to have a look. But it wanted to drag in a ridiculous number of dependencies, most of them devel packages.
Surely a precompiled non-devel RPM shouldn't be dragging in development
packages? That's got to be a major design screw up. Doesn't
incorporating a package into a repo involve some sort of checking
procedure to reject packages trying to do that sort of nonsense? (Non-devel packages depending on devel packages.)
Yes, the initial review before a new package is accepted into the Fedora Collection. But later on, the packager can update the package without needing any review. Usually that's when packaging bugs return into the package.
<snip>
Quite often, those -devel packages have library files included on which the non-devel package depends.
Uhm, exactly *that* would be a packaging bug. ;)
Packages that depend on the kernel-devel packages spring to mind, but many others do, as well.
Many others? Hopefully not. Here it's:
--> Processing Dependency: evolution-data-server-devel >= 1.4.0 for package: gnome-python2-evolution
Summary : Python bindings for interacting with evolution-data-server Description : This module contains a wrapper that allows the use of evolution-data-server via Python.
# rpm -qpl gnome-python2-evolution-2.22.0-4.fc10.i386.rpm /usr/lib/python2.5/site-packages/gtk-2.0/evolution /usr/lib/python2.5/site-packages/gtk-2.0/evolution/__init__.py /usr/lib/python2.5/site-packages/gtk-2.0/evolution/__init__.pyc /usr/lib/python2.5/site-packages/gtk-2.0/evolution/__init__.pyo /usr/lib/python2.5/site-packages/gtk-2.0/evolution/ebook.so /usr/lib/python2.5/site-packages/gtk-2.0/evolution/ecal.so
It contains an explicit dependency on
evolution-data-server-devel >= 1.4.0
without a comment in the spec file.
Mike Burger wrote:
The issue was that the NessusClient application, compiled for Fedora 9, includes a copy of various QT libraries, and the installation process places them in /opt/nessus/lib, places an entry in /etc/ld.so.conf, pointing at that directory, and then runs ldconfig.
Because there were pointers at incompatible QT libraries, the process of logging into KDE4 became non-functional. Commenting out the /opt/nessus/lib line and rerunning ldconfig fixed it for me (thanks to Rex Dieter for helping me get my head back out of my tuchas on that one)
Speaking of that (sorry, thread hijack warning), would you mind letting the folks you got the NessusClient rpm from, that it's breaking peoples f9 systems?
Otherwise, gimme a pointer, and I'll sic my fedora ninja monkeys on them.
I might let you do that, anyhow...however, I did file a bugzilla report with them, once we got that figured out.
On Tue, 2008-06-03 at 09:49 -0400, Mike Burger wrote:
Quite often, those -devel packages have library files included on which the non-devel package depends. Packages that depend on the kernel-devel packages spring to mind, but many others do, as well.
It rather begs the question though: why does a package have a library that the package itself doesn't depend on? e.g. xine-lib-devel includes /usr/lib64/libxine.so but xine itself doesn't. Wierd.
I'd wager that xine has libxine statically linked and/or compiled in.
On Tue, 3 Jun 2008 10:56:30 -0400 (EDT), Mike Burger wrote:
On Tue, 2008-06-03 at 09:49 -0400, Mike Burger wrote:
Quite often, those -devel packages have library files included on which the non-devel package depends. Packages that depend on the kernel-devel packages spring to mind, but many others do, as well.
It rather begs the question though: why does a package have a library that the package itself doesn't depend on? e.g. xine-lib-devel includes /usr/lib64/libxine.so but xine itself doesn't. Wierd.
I'd wager that xine has libxine statically linked and/or compiled in.
No, libxine.so is just a symlink pointing to the real and versioned library file in the xine-lib package. This symlink is needed only when building software -- it's the link that makes the -lxine linker command work.
Michael Schwendt wrote:
I'd wager that xine has libxine statically linked and/or compiled in.
No, libxine.so is just a symlink pointing to the real and versioned library file in the xine-lib package. This symlink is needed only when building software -- it's the link that makes the -lxine linker command work.
Yes, Redhat and Fedora have always done this.
The executables look for <library>.so.<version> and that is a symlink to <library>.so.<full-version> in one of the ld.so.conf paths.
On Tue, 03 Jun 2008 16:49:52 +0100, Brian Morrison wrote:
Michael Schwendt wrote:
I'd wager that xine has libxine statically linked and/or compiled in.
No, libxine.so is just a symlink pointing to the real and versioned library file in the xine-lib package. This symlink is needed only when building software -- it's the link that makes the -lxine linker command work.
Yes, Redhat and Fedora have always done this.
The executables look for <library>.so.<version> and that is a symlink to <library>.so.<full-version> in one of the ld.so.conf paths.
It's the "right thing to do" and not specific to Red Hat or Fedora.
-
Brian Morrison -
Michael Schwendt -
Mike Burger -
Patrick O'Callaghan -
Rex Dieter -
Tim