Xulrunner is being removed from the tree; as per bug 380485 the newer versions of vlc have dropped nsplugin support in favour of an external package, however vlc-1.1.13 and vlc-1.1.9999 still depend on xulrunner. The patch in bug 380485 will swap the dep of xulrunner for npapi-sdk in an install-on-disk-identical way (note that vlc's plugin code does not actually link against xulrunner, it just uses some headers), so as far as I am concerned this update could occur in place without changing KEYWORDS. Also mentioned in the bug was that the external plugin package works in 1.1 and so it might be better to just drop the flag completely from the 1.1 ebuilds (which I think can also be done without changing KEYWORDS). Removal of the 1.1 ebuilds after stabilization of 2.x would of course also suffice. Linking this bug to the drop-xulrunner-tracker
please mask the nsplugin flag in base/package.use.mask
(In reply to comment #1) > please mask the nsplugin flag in base/package.use.mask done, although I have to say I don't like this solution much (since we still need to keep this bug open pending on =media-video/vlc-1.1* removal now I suppose :-/)
Is there a =media-video/vlc-2* stabilization bug open yet we could make this bug depend on?
(In reply to comment #3) > Is there a =media-video/vlc-2* stabilization bug open yet we could make this > bug depend on? I think bug #408881 may be a candidate for that.
Sorry, I'm not sure if I understand the situation right, but I'm running stable vlc (1.1.13 on amd64) with the nsplugin USE flag enabled, and if I now emerge vlc, it would disable that flag due to the use mask that is being discussed here. So I won't have the browser plugin anymore, right? I guess that switching to vlc-2.0.0 (unstable, ~amd64) would fix the problem, but is there any way to have the browser plugin on stable? I'm not such an expert on these things, but if just waiting for 2.0.0 to become stable would have fixed this bug, I really don't see why users of stable now should have their vlc plugin dropped, with no news, either. I only noticed this because I read the "emerge -va" output before confirming.
I forgot: the problem is fixed with vlc-2.0.0 only because then I can install npapi-vlc-2.0.0 (unstable, that depends on it). There is no npapi-vlc-1.1.x in the tree.
you might want to see if the npapi-vlc package will work with vlc-1.x, however yes the permanent solution will be for vlc-2 to go stable.
Fixed.