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