multi-path (Was: [ANN] nspluginwrapper 1.2.0)
Gwenole Beauchesne
gb.public at free.fr
Mon Dec 29 07:58:20 UTC 2008
Hi,
Le 28 déc. 08 à 03:27, Warren Togami a écrit :
> Gwenole Beauchesne wrote:
>>> http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/nspluginwrapper-1.1.8-directory.patch?view=log
>>> Why is this not upstream?
>> IIRC, your patch is more to change nspluginwrapper libdirs
>> actually, isn't it? i.e. have /usr/lib/nspluginwrapper and /usr/
>> lib64/nspluginwrapper. This approach is very specific to Linux i386/
>> x86_64 architectures. I still prefer the NPW_PREFIX/ARCH/OS/
>> hierarchy because it's also desirable to support Windows plugins,
>> and the run-time will be available in */i386/windows/. Maybe /usr/
>> libexec is a better location? Though, neither FHS nor LSB mention
>> it for Linux IIRC.
>
> /usr/libexec is a GNU standard, but it is not appropriate for this
> at all. nspluginwrapper on Fedora/RHEL has independent builds and
> binary packages that can be installed on i386 and x86_64. For
> example, Fedora x86_64 installs only nspluginwrapper.x86_64 by
> default.
And why is the current hierarchy not appropriate? Everything is well
separated and it should not even be a packaging tool problem. AFAIK,
pkglibdir/noarch/npviewer is a shell script so it is not assigned any
color. In that case, the conflict-check is relaxed and does not
include timestamps.
It is already possible to build native arch trees: configure --target-
cpu=%{_arch}. In that case, 32-/64-bit build at once is disabled and
you only get "native" binaries, though in pkglibdir/ARCH/linux/.
Regards,
Gwenole.
More information about the Nspluginwrapper-devel-list
mailing list