8:02 a.m.
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
--
[tim@localhost ~]$ uname -r
2.6.25.3-18.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
10:49 a.m.
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.
--
Brian
12:06 p.m.
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.
10:08 a.m.
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.
--
Fedora release 9.90 (Rawhide) - Linux 2.6.26-0.45.rc4.git2.fc10.i686
loadavg: 1.30 1.60 1.58
9:56 a.m.
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.
--
Mike Burger
http://www.bubbanfriends.org
Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org
To be notified of updates to the web site, visit:
https://www.bubbanfriends.org/mailman/listinfo/site-update
or send a blank email message to:
site-update-subscribe(a)bubbanfriends.org
9:55 a.m.
New subject: NessusClient's embedded qt4 busted
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.
--
Mike Burger
http://www.bubbanfriends.org
Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org
To be notified of updates to the web site, visit:
https://www.bubbanfriends.org/mailman/listinfo/site-update
or send a blank email message to:
site-update-subscribe(a)bubbanfriends.org
9:49 a.m.
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.
--
Fedora release 9.90 (Rawhide) - Linux 2.6.26-0.45.rc4.git2.fc10.i686
loadavg: 1.21 1.62 1.74
9:24 a.m.
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
9:16 a.m.
New subject: NessusClient's embedded qt4 busted
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
8:49 a.m.
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
http://www.bubbanfriends.org
Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org
To be notified of updates to the web site, visit:
https://www.bubbanfriends.org/mailman/listinfo/site-update
or send a blank email message to:
site-update-subscribe(a)bubbanfriends.org
5866
days inactive
5866
days old
9 comments
6 participants
participants (6)
-
Brian Morrison -
Michael Schwendt -
Mike Burger -
Patrick O'Callaghan -
Rex Dieter -
Tim