acroread should use "mozilla" flag to enable or disable the web plugin installation. Reproducible: Always Steps to Reproduce: 1.emerge -pv acroread Actual Results: These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-text/acroread-7.0.0.2-r1 -cjk -ldap -noplugin 0 kB Total size of downloads: 0 kB Expected Results: These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-text/acroread-7.0.0.2-r1 -cjk -ldap mozilla 0 kB Total size of downloads: 0 kB
This seems like a better solution to my bug #59594. It seems sensible from the point of view of minimizing custom use flags. My only concern would be whether this makes since for the non-mozilla browsers that use netscape plugins (I think konqueror might but I'm not a KDE user). Does this proposed solution make sense for those users? The description of the mozilla flag is "Adds support for mozilla"...
(In reply to comment #1) > My only concern would be whether this makes since for the non-mozilla browsers > that use netscape plugins (I think konqueror might but I'm not a KDE user) I am a KDe user and, indeed, Konqueror uses mozilla plugins. > Does this proposed solution make sense for those users? The description of the > mozilla flag is "Adds support for mozilla"... I wouldn't directly associate that description with a plugin for konqueror. I'ld probably check the ebuild and figure it out, but still... Additionally and IIRC, Opera will also make use of mozilla plugins. Epiphany joins the crowd and is, while gecko-based, not developed by the mozilla but by the GNOME project. And I probably forgot a bunch of more obscure projects. So, for all practical purposes, the Mozilla plugin API is *the* API for browser plugins under *nix. IMNSHO, a "mozilla" keyword that effectively enables or disables the compilation of an optional browser plugin for basically all popular and not-so-popular browsers is a misnomer. I'ld rather have a global USE flag called "plugin" or something along those lines. The question is, is this needed? Is acroread unique in that it optionally compiles a plugin? Or are there more packages like it (packages that are nothing but plugins don't count, obviously)?
media-video/helixplayer media-video/gxine dev-lang/squeak media-video/realplayer all use mozilla for enabling/disabling the plugin. A local flag similar to the acroread one is only used by djvu: /usr/portage/profiles/use.local.desc:app-text/acroread:noplugin - Do not install the acroread browser plugin /usr/portage/profiles/use.local.desc:app-text/djvu:nsplugin - Builds plugins for Netscape compatible browsers I moved the IUSE to mozilla in the latest ebuild, you can use /etc/portage/package.use if you want to have mozilla only for this ebuild. Oh, and the new global use flag idea should be discussed on gentoo-dev <at> lists.gentoo.org before anything can be done.
what about a generic "nsplugin" USE-flag for all packages which provides Netscape compatible plugins? If I see just "mozilla", I would think, it's for Mozilla/Firefox only.
As per comment 3, this ebuild and djvu should use "mozilla" to match the other ebuilds mentioned. I agree with comment #4 that it might be worth adding a nsplugin global use flag, though as pointed out in comment #3, this would need to be discussed elsewhere. FWIW, I don't think it should be called nsplugin though as there are probably those out there who have never heard of Netscape. Perhaps open another bug listing all ebuilds in the tree with use the mozilla use flag to enable a browser plugin and start some discussion there...?
