/usr/lib/nsbrowser/plugins/ is the default path for plugins but it contains logical links only to lib directories vlc is installing files there directly, libvlcplugin.la libvlcplugin.so including a .la file Please move the real file to vlc lib directly and add a symlink the to nsbrowser path
I'm sorry but I don't understand what is the problem with having the file there, thus closing as worksforme. However, I don't mind changing it as you suggest but then please provide a patch to vlc-9999.ebuild and reopen, thanks.
Created attachment 239543 [details, diff] change the install path (against vlc-9999) patch to install plugin in /usr/lib/vlc/plugins and symlink it to /usr/lib/nsbrower/plugins
Dear Alexies i'm not expect of gentoo ebuild syntax, please give a look to the patch as reference, it's really small and clean i'm not sure we need the .la file too, if so just add a new symlink line.
But *why* this should be done? I still don't see a reason here.
to allow all packages to install in their own path, and do not spread plugins here and there. i mean: this is what is already done byseveral packages (lightspark, moonlight for istance). flash is in /opt due to binary form too. java nsplugin, same depending on the used jre they all install somewhere and then add a symlink. so as...let's call it RFC i'm suggesting a clean way to handle plugins instead of having symlinks and files mixed and vlc is the only one i'm aware missing this style.
Created attachment 240895 [details, diff] fixup where the plugin is actually installed to eliminate empty dirs from being installed on ${ROOT} This does not make much sense, the flash and java are only using symlinks due to the maintainers preference. I for one do not need an empty /usr/lib64/mozilla dir so fix it to just install to /usr/$(get_libdir)/nsbrowser as it should be.
Created attachment 240897 [details, diff] remove nsplugins eclass use as it is no longer needed Sorry forgot to remove the nsplugin inherit which will no longer be needed.
Jory, ok fine for cleaning up but this is not the solution for the problem i pointed out
(In reply to comment #8) > Jory, ok fine for cleaning up but this is not the solution for the problem i > pointed out > What you pointed out is not a problem. Your pointing out things you do not like is all, if you want to see the plugin location changed completely you should file the bug report with upstream. There is no point in the plugin being installed in /usr/$(get_libdir)/vlc/plugins/ that is not where it belongs at all.
i totally agree with u regarding not being a "problem". it's a way to tidy up things and make them uniform. nsbrowser is the gentoo customized path so upstream will never accept this. plus, i may say that's no point in the vlc install script containing the "nsbrowser" reference. all this to mean: if you replace "mozilla" with nsplugins you can put them in the vlc plugins path too.
VLC per default installs it's plugin to /usr/$(get_libdir)/mozilla/plugins where it should not go to. Firefox for instance does not recognize plugins there. Personally I don't care if it goes to /usr/$(get_libdir)/nsbrowser/plugins directly or into the vlc lib dir with a symlink pointing to it from the former. Independent of all this I agree with Jory that there shouldn't be empty direcories installed, so why not either applying his patch or just remove the mozilla directory in src_install by adding rm -rf "${D}"/usr/$(get_libdir)/mozilla to the nsplugin code block.
(In reply to comment #11) > Independent of all this I agree with Jory that there shouldn't be empty > direcories installed, so why not either applying his patch or just remove the > mozilla directory in src_install by adding rm -rf > "${D}"/usr/$(get_libdir)/mozilla to the nsplugin code block. > The rm -rf would be incorrect as well since he already inherits nsplugins.eclass which has a function to move the plugin then remove the dir. I suggest he just lands the patch I provided him and keep our plugins uniform in gentoo.
I was meaning to add the qa herd to ensure this is resolved rather soon, I am very disappointed that this has taken so long to resolve. Installing an empty directory is not appropriate and can lead to bigger issues later.
(In reply to comment #12) > The rm -rf would be incorrect as well since he already inherits > nsplugins.eclass which has a function to move the plugin then remove the dir. I > suggest he just lands the patch I provided him and keep our plugins uniform in > gentoo. Only if src_mv_plugins() or pkg_mv_plugins() are actually used, or am I wrong?
(In reply to comment #14) > (In reply to comment #12) > > The rm -rf would be incorrect as well since he already inherits > > nsplugins.eclass which has a function to move the plugin then remove the dir. I > > suggest he just lands the patch I provided him and keep our plugins uniform in > > gentoo. > > Only if src_mv_plugins() or pkg_mv_plugins() are actually used, or am I wrong? > Billie this is correct, I never have understood why he inherits the eclass if he is not gonna make use of all the benefits of it.
(In reply to comment #15) > Billie this is correct, I never have understood why he inherits the eclass if > he is not gonna make use of all the benefits of it. He uses at least the ${PLUGINS_DIR} variable which ensures a uniform plugin install path. While looking at this further, I don't think using pkg_mv_plugins() from the eclass is a good idea as portage does not know about the new plugin location and still lists the files from the old directory in it's contents. So the only useful things from this eclass are the ${PLUGINS_DIR} var and src_mv_plugins() and inst_plugin().
(In reply to comment #13) > I was meaning to add the qa herd to ensure this is resolved rather soon, I am > very disappointed that this has taken so long to resolve. Installing an empty > directory is not appropriate and can lead to bigger issues later. You can be disappointed but I already answered you iirc: please provide a patch that can be upstreamed. Such a sed hack can only be meant for a temporary solution knowing this will be handled in a better way in future versions. If you want I can handle upstreaming it but it's better if you do so that you preserve authorship for your work.
nothing for mozilla team here.
There is no projects folder anymore; if I understand correctly, this has moved to http://git.videolan.org/?p=npapi-vlc.git and a quick file search for libvlcplugin.so confirms that. Therefore I move this bug to that package.
(In reply to Alexis Ballier from comment #17) > (In reply to comment #13) > > I was meaning to add the qa herd to ensure this is resolved rather soon, I am > > very disappointed that this has taken so long to resolve. Installing an empty > > directory is not appropriate and can lead to bigger issues later. > > You can be disappointed but I already answered you iirc: please provide a > patch that can be upstreamed. Such a sed hack can only be meant for a > temporary solution knowing this will be handled in a better way in future > versions. > > If you want I can handle upstreaming it but it's better if you do so that > you preserve authorship for your work.
