9:17 a.m.
Hello,
I was curious how many library packages we have that also includes applications in
them, so I wrote a small shell script:
http://people.redhat.com/sgrubb/security/lib-bin-check
On my F16 installation, it finds around 60 packages that are libraries with
applications. I'd like to ask if anyone else sees this as a problem? For example, if a
32 bit library is installed, which application is left - the 64 or 32 bit one? And
wouldn't that also pull in unnecessary dependencies?
-Steve
9:20 a.m.
On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
Hello,
I was curious how many library packages we have that also includes applications in
them, so I wrote a small shell script:
http://people.redhat.com/sgrubb/security/lib-bin-check
That just checks for a path. It doesn't check if the "application" is
just a shell script, which is noarch.
On my F16 installation, it finds around 60 packages that are
libraries with
applications. I'd like to ask if anyone else sees this as a problem? For example, if
a
32 bit library is installed, which application is left - the 64 or 32 bit one? And
wouldn't that also pull in unnecessary dependencies?
Again, not if it's noarch. The list of packages you found with
problems would have been nice.
josh
9:26 a.m.
On Sunday, November 20, 2011 10:20:51 AM Josh Boyer wrote:
On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb
<sgrubb(a)redhat.com> wrote:
> Hello,
>
> I was curious how many library packages we have that also includes
> applications in them, so I wrote a small shell script:
>
> http://people.redhat.com/sgrubb/security/lib-bin-check
That just checks for a path. It doesn't check if the "application" is
just a shell script, which is noarch.
OK, simple fix. I'll post an improved script in a little while.
> On my F16 installation, it finds around 60 packages that are
libraries
> with applications. I'd like to ask if anyone else sees this as a
> problem? For example, if a 32 bit library is installed, which
> application is left - the 64 or 32 bit one? And wouldn't that also pull
> in unnecessary dependencies?
Again, not if it's noarch. The list of packages you found with
problems would have been nice.
After I fix the script, I'll post the packages.
-Steve
10:30 a.m.
On Sunday, November 20, 2011 10:26:09 AM Steve Grubb wrote:
On Sunday, November 20, 2011 10:20:51 AM Josh Boyer wrote:
> On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > Hello,
> >
> > I was curious how many library packages we have that also includes
> > applications in them, so I wrote a small shell script:
> >
> > http://people.redhat.com/sgrubb/security/lib-bin-check
>
> That just checks for a path. It doesn't check if the "application"
is
> just a shell script, which is noarch.
New script posted. This dropped the list by about half.
> > On my F16 installation, it finds around 60 packages that
are libraries
> > with applications. I'd like to ask if anyone else sees this as a
> > problem? For example, if a 32 bit library is installed, which
> > application is left - the 64 or 32 bit one? And wouldn't that also pull
> > in unnecessary dependencies?
>
> Again, not if it's noarch. The list of packages you found with
> problems would have been nice.
libreport-gtk-2.0.6.x86_64
libgnome-2.32.1.x86_64
libtar-1.2.11.x86_64
libreport-newt-2.0.6.x86_64
libgpg-error-1.10.x86_64
libEMF-1.0.4.x86_64
libnotify-0.7.4.x86_64
libselinux-2.1.6.x86_64
libiptcdata-1.0.4.x86_64
libsamplerate-0.1.8.x86_64
libkgeomap-2.3.0.x86_64
libgnomekbd-3.2.0.x86_64
libmsn-4.2.x86_64
libmx-1.4.0.x86_64
libreport-2.0.6.x86_64
libxslt-1.1.26.x86_64
libvirt-0.9.6.x86_64
libcanberra-0.28.x86_64
libtunepimp-0.5.3.x86_64
libidn-1.22.x86_64
libcanberra-gtk3-0.28.x86_64
libgnome-media-profiles-3.0.0.x86_64
libhangul-0.0.12.x86_64
libcroco-0.6.2.x86_64
libkactivities-6.1.x86_64
libieee1284-0.2.11.x86_64
libgpod-0.8.2.x86_64
libwnck3-3.2.1.x86_64
But this is just my system and not an everything install.
-Steve
1:03 p.m.
Steve Grubb wrote:
For example, if a 32 bit library is installed, which application is
left -
the 64 or 32 bit one?
If you install ONLY the 32-bit multilib, the 32-bit version.
If you install BOTH the 64-bit and 32-bit packages, the 64-bit version (on
all the platforms where 64-bit is preferred, which includes x86_64 and now
also ppc64).
If you install ONLY the 64-bit package, the 64-bit version.
Kevin Kofler
1:14 p.m.
On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Steve Grubb wrote:
> For example, if a 32 bit library is installed, which application is left -
> the 64 or 32 bit one?
If you install ONLY the 32-bit multilib, the 32-bit version.
If you install BOTH the 64-bit and 32-bit packages, the 64-bit version (on
all the platforms where 64-bit is preferred, which includes x86_64 and now
also ppc64).
If you install ONLY the 64-bit package, the 64-bit version.
Yeah which means there isn't really a problem here.
1:33 p.m.
On Sunday, November 20, 2011 02:14:09 PM drago01 wrote:
On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler
<kevin.kofler(a)chello.at> wrote:
> Steve Grubb wrote:
>> For example, if a 32 bit library is installed, which application is left
>> - the 64 or 32 bit one?
>
> If you install ONLY the 32-bit multilib, the 32-bit version.
> If you install BOTH the 64-bit and 32-bit packages, the 64-bit version
> (on all the platforms where 64-bit is preferred, which includes x86_64
> and now also ppc64).
> If you install ONLY the 64-bit package, the 64-bit version.
Yeah which means there isn't really a problem here.
Well, yeah there is the other problem of dependencies and getting a smaller minimal
install. For example, libnotify.
# ldd /usr/bin/notify-send | wc -l
44
# ldd /usr/lib64/libnotify.so.1.2.3 | wc -l
12
or how about libmsn
# ldd /usr/bin/msntest | wc -l
20
# ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
9
I didn't test all of them, but the extra dependencies are unneeded.
-Steve
2:05 p.m.
On Sun, Nov 20, 2011 at 02:33:34PM -0500, Steve Grubb wrote:
On Sunday, November 20, 2011 02:14:09 PM drago01 wrote:
> On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
> > Steve Grubb wrote:
> >> For example, if a 32 bit library is installed, which application is left
> >> - the 64 or 32 bit one?
> >
> > If you install ONLY the 32-bit multilib, the 32-bit version.
> > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version
> > (on all the platforms where 64-bit is preferred, which includes x86_64
> > and now also ppc64).
> > If you install ONLY the 64-bit package, the 64-bit version.
>
> Yeah which means there isn't really a problem here.
Well, yeah there is the other problem of dependencies and getting a smaller minimal
install. For example, libnotify.
# ldd /usr/bin/notify-send | wc -l
44
# ldd /usr/lib64/libnotify.so.1.2.3 | wc -l
12
or how about libmsn
# ldd /usr/bin/msntest | wc -l
20
# ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
9
I didn't test all of them, but the extra dependencies are unneeded.
This is a different problem -- it should be solved with subpackages (putting
the applications in a separate subpackage from the library). Opening bugs,
proposing patches, and exercising provenpackager abilities to resolve these
is generally appreciated. Do be careful of the few packages where currently
packages assume the utilities are in the library package and not having them
there may subtly change desired behaviour. (I think most of those will be
present on this page:
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets
)
-Toshio
3:36 p.m.
On Sun, Nov 20, 2011 at 19:33, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Sunday, November 20, 2011 02:14:09 PM drago01 wrote:
> On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
> > Steve Grubb wrote:
> >> For example, if a 32 bit library is installed, which application is left
> >> - the 64 or 32 bit one?
> >
> > If you install ONLY the 32-bit multilib, the 32-bit version.
> > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version
> > (on all the platforms where 64-bit is preferred, which includes x86_64
> > and now also ppc64).
> > If you install ONLY the 64-bit package, the 64-bit version.
>
> Yeah which means there isn't really a problem here.
Well, yeah there is the other problem of dependencies and getting a smaller minimal
install. For example, libnotify.
# ldd /usr/bin/notify-send | wc -l
44
# ldd /usr/lib64/libnotify.so.1.2.3 | wc -l
12
or how about libmsn
# ldd /usr/bin/msntest | wc -l
20
# ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
9
I am the maintainer of libmsn. msntest probably could be moved to a
subpackage but it is a small program. All of the dependencies found by
ldd are already required by the applications using libmsn and msntest
is also very useful for checking if a problem connecting to msn is
caused by libmsn or the settings/applications using it. I would be
happy to move msntest into a subpackage if it is specifically
requested but under the current circumstances it would gain nothing
and just add an extra package to the repos.
--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
2:53 a.m.
On Sun, 2011-11-20 at 21:36 +0000, John5342 wrote:
On Sun, Nov 20, 2011 at 19:33, Steve Grubb <sgrubb(a)redhat.com>
wrote:
> On Sunday, November 20, 2011 02:14:09 PM drago01 wrote:
>> On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
>> > Steve Grubb wrote:
>> >> For example, if a 32 bit library is installed, which application is
left
>> >> - the 64 or 32 bit one?
>> >
>> > If you install ONLY the 32-bit multilib, the 32-bit version.
>> > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version
>> > (on all the platforms where 64-bit is preferred, which includes x86_64
>> > and now also ppc64).
>> > If you install ONLY the 64-bit package, the 64-bit version.
>>
>> Yeah which means there isn't really a problem here.
>
> Well, yeah there is the other problem of dependencies and getting a smaller minimal
> install. For example, libnotify.
>
> # ldd /usr/bin/notify-send | wc -l
> 44
> # ldd /usr/lib64/libnotify.so.1.2.3 | wc -l
> 12
>
> or how about libmsn
> # ldd /usr/bin/msntest | wc -l
> 20
> # ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
> 9
I am the maintainer of libmsn. msntest probably could be moved to a
subpackage but it is a small program. All of the dependencies found by
ldd are already required by the applications using libmsn and msntest
is also very useful for checking if a problem connecting to msn is
caused by libmsn or the settings/applications using it. I would be
happy to move msntest into a subpackage if it is specifically
requested but under the current circumstances it would gain nothing
and just add an extra package to the repos.
Exactly. In case the binaries shipped along with the library do not pull
any additional dependencies and they are reasonably small, there is no
need to put them into extra subpackages. At least not until rpm drops
the multilib and file-coloring support.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
4:46 a.m.
On Sun, Nov 20, 2011 at 02:33:34PM -0500, Steve Grubb wrote:
# ldd /usr/bin/msntest | wc -l
20
# ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
9
Please, be careful. ldd(1) prints recursively all dependencies.
$ ldd /usr/bin/msntest | wc -l
20
$ readelf -a /usr/bin/msntest | grep NEEDED | wc -l
8
It means that the /usr/bin/msntest depends on 8 libraries only.
I didn't test all of them, but the extra dependencies are
unneeded.
Yes, typical problem is (usually) completely broken .pc (pkg-config)
file. My experience is that developers don't have a clue about
'Requires.private' pkg-config field and they add all libraries to
'Requires' or 'Libs', so then binaries are linked with many
unnecessary libraries (possible workaround is --as-needed ld(1)
option).
man pkg-config:
In the situation where each .pc file corresponds to a library,
Requires.private shall be used exclusively to specify the
dependencies between the libraries.
$ pkg-config --libs gtk+-3.0
-pthread -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
-lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpng12 -lm -lcairo-gobject -lcairo
-lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lrt -lglib-2.0
... I don't believe that gtk ABI contains symbols from all this
libraries :-)
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
7:42 a.m.
On Tue, 2011-11-22 at 11:46 +0100, Karel Zak wrote:
Yes, typical problem is (usually) completely broken .pc (pkg-config)
file. My experience is that developers don't have a clue about
'Requires.private' pkg-config field and they add all libraries to
'Requires' or 'Libs', so then binaries are linked with many
unnecessary libraries (possible workaround is --as-needed ld(1)
option).
man pkg-config:
In the situation where each .pc file corresponds to a library,
Requires.private shall be used exclusively to specify the
dependencies between the libraries.
You have to be careful when you read documentation as well.
That 'shall' sentence is a bit of a propaganda piece. In reality, things
are not as black-and-white.
$ pkg-config --libs gtk+-3.0
-pthread -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
-lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpng12 -lm -lcairo-gobject -lcairo
-lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lrt -lglib-2.0
... I don't believe that gtk ABI contains symbols from all this
libraries :-)
Well, the pkg-config output effectively states that they are.
And changing it now will cause breakage. We already experienced that
when I removed the -lpng12 and -lm from the gdk-pixbuf pc file.
5:10 p.m.
Does anybody know of anything I can try in Fedora 16 to get the other half
of my files from the Deja DUP backup?
Thanks,
Richard
On Nov 20, 2011 7:17 AM, "Steve Grubb" <sgrubb(a)redhat.com> wrote:
Hello,
I was curious how many library packages we have that also includes
applications in
them, so I wrote a small shell script:
http://people.redhat.com/sgrubb/security/lib-bin-check
On my F16 installation, it finds around 60 packages that are libraries with
applications. I'd like to ask if anyone else sees this as a problem? For
example, if a
32 bit library is installed, which application is left - the 64 or 32 bit
one? And
wouldn't that also pull in unnecessary dependencies?
-Steve
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4600
days inactive
4602
days old
12 comments
10 participants
participants (10)
-
drago01 -
John5342 -
Josh Boyer -
Karel Zak -
Kevin Kofler -
Matthias Clasen -
Richard Vickery -
Steve Grubb -
Tomas Mraz -
Toshio Kuratomi