On 12/27/06, Callum Lerwick <seg@xxxxxxxxxx> wrote:
firefox = 1.5.foo.bar ...
I'm thinking this is the best way to prevent this situation from going
unnoticed by the currently available rpm dep checking. It's a policy
fix. Make an explicit check during the review process to ensure that a
versioned firefox requires is used if and only if libraries from
inside the versioned firefox directory tree are pulled in as requires.
We may want to think about this as part of Core package review for the
upcoming merger.
Is anyone got a few spare cycles to script a Core+Extras wide check
looking for all packages which end up requiring shared libraries
required by firefox? My frelling home workstation died, so I don't
have my normal development environment at my fingertips. I'm thinking
we can brute-force this with some repetitive calls of repoquery
--whatrequires using the output rpm -q --provides firefox |grep \.so
Doing some simple exploratory surgery with rpm --provides and
--whatrequires I noticed that esc doesn't actually require
libxpcom.so. I took a closer look at the esc in Core 6 and the esc
situation is even more confusing than I originally thought.
esc-1.0.0-16.fc6 actually includes its own copy of
/usr/lib/esc-1.0.0/xulrunner/libxpcom.so
but ldd /usr/lib/esc-1.0.0/xulrunner/xulrunner-bin returns:
libmozjs.so => not found
libxpcom.so => not found
libxul.so => not found
I'd be interested to know if esc in the development tree as a similiar problem.
All three of these libraries are provided by firefox AND by esc
itself. WTF. esc's specfile must completely short-circuit rpm's normal
auto-generation of library dependancies, and according to the
changelog entries it does short circuit the process. Whereever esc's
xulrunner-bin is looking for libxpcom.so its not from its own
xulrunner library directory nor from any firefox versioned directory
of any firefox rpm released for fc6 afaict. I'm gonna have to try to
file this in bugzilla tomorrow. Something tells me I'm going to need
a couple of ultra-strong eye-poking sticks. I might even have to buy
the white-hot heated upgrade this time.
-jef"Is it okay if I make MST3K-like commentary on some of the more
interesting Core package reviews when they start happening. The esc
review is already on my short-list. I want to understand wtf is so
wrong with esc's build process that automatic library dependency
calculations had to be explictly turned off. There is absolutely no
way to catch that xulrunner-bin is missing library references at the
packaging level as it stands. I had to blunder into this looking for
other problems on an installed system. I'm coming to this review with
a large tub of popcorn and bat wielding sock puppets."spaleta
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
