Dan Nicholson wrote these words on 02/03/06 17:27 CST:
> I prefer this way. What if plugins such as libnullplugin.so are
> incompatible between Mozilla-1.7 and Firefox-1.5? I think there's
> plenty of information in the book about the plugins. If someone wants
> to create a central repo of plugins in /usr/lib/mozilla/plugins, I
> think they can figure out how to do this.
I think you grasped what I was asking here, and you provided an
answer, however, I don't think that compatibility is an issue. Firefox
and Mozilla each will install their own copy of libnullplugin.so in
the respective plugin directory of each package. Each package uses
its own copy.
I'm more thinking about the plugins that are put in
/usr/lib/mozilla/plugins by 3rd party programs. I now feel like you
Dan, that we should just leave them there, and let folks link to
them, copy them, whatever they want to do. I'm leaning to not doing
a darn thing about the plugins dir, other than do like the Firefox
instructions and say, "you can copy or link to any existing plugins
you may have in /usr/lib/mozilla/plugins".
>>2) Do we need to continue to maintain this support for broken
>>programs (don't check pkgconfig files) that currently in the book
>>we make /usr/lib/mozilla and /usr/include/mozilla symlinks to the
>>appropriate versioned directories so that "programs don't have to
>>know which version of Mozilla is installed"?
>
> You may have two versions of the mozilla based browser that have
> incompatible backends (1.7 vs. 1.8). So, I'd prefer if these packages
> were patched so that they install into the specific plugin directory
> of the libraries they were compiled against. For example, if you
> compile librsvg against firefox-1.5 by passing
> --with-mozilla=whatever, then I think the plugin in should go into
> whatever's plugin dir.
I'm not sure you understood what I was asking here. It is nothing
to do about plugins. It is about the fact that currently in the
Mozilla instructions, there are commands to create links from
/usr/lib/mozilla and /usr/include/mozilla to the respective dirs
in the /usr/{lib,include}/mozilla-1.7.12 tree.
This is because, as the book says, "We set up to provide for stupid
broken programs that don't know to look for libraries and header
files in /usr/lib/mozilla-1.7.12 and /usr/include/mozilla-1.7.12"
So, we create the /usr/lib/mozilla and /usr/include/mozilla symlinks
to satisfy these stupid broken programs that only look here for
libs and includes.
I'm saying we should ditch this support for the stupid, broken
programs. Bruce had a good idea, sent offline, in that we perhaps
should remove these commands to create the links and actually see
if there is any breakage, and if so, report it upstream and/or
patch the problem.
Hopefully this clears up the meaning of what I was trying to ask.
--
Randy
rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
17:46:00 up 132 days, 3:10, 3 users, load average: 0.00, 0.00, 0.12
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
