[Bug 236521] Review Request: nspluginwrapper - A compatibility layer for Mozilla/Firefox plugins

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: nspluginwrapper - A compatibility layer for Mozilla/Firefox plugins
Alias: nspluginwrapper

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236521


jakub at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat.com




------- Additional Comments From jakub at redhat.com  2007-06-07 08:21 EST -------
Sorry for late reply, forgot to add me into CC.
The reason to remove %{_bindir}/nspluginwrapper was that that would clash.
Say on ppc if you want 64-bit nspluginwrapper with ppc target_arch
and 32-bit nspluginwrapper with ppc64 target_arch at the same time, what
would %{_bindir}/nspluginwrapper point to?
Ideally the configuration program would be changed, so that it finds out
what nspluginwrapper host versions are available, what their target arch is
and depending on the architecture of the target plugin you want to install into
nspluginwrapper it would register it for all hosts that have those target_arch
configured.  So, if you have ppc -> ppc64 and ppc64 -> ppc nspluginwrapper,
running the proglet to install 32-bit plugin would register it in the 64-bit
nspluginwrapper and vice versa.

Regarding npwrapper.so symlink, perhaps rpmlint was quite on your package,
that doesn't mean it was correct.
ln -s npwrapper.so %{buildroot}%{nslibdir}/mozilla/plugins/npwrapper.so
creates a symlink pointing to itself (i.e. a symlink loop).

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.