An alternative came to mind, how about removing version check and adding an AC_whatever check? No idea about what changes mozilla-plugin version 8 (version 2, in openvrml case) introduced.
On Thu, Jul 17, 2014 at 08:03:25PM +0200, Matthias Klumpp wrote: > That patch looks good to me, I could even apply it upstream. Is > npapi-sdk a Debian-specific thing, or is it something other > distributions will use as well soon? > I also wonder if patching all downstream projects is the right way to > solve this issue, but I don't know much about NPAPI (if 0.27 is the > real API version number, then patching them is the right thing to do - > otherwise for real compatibility with stuff that depended on > mozilla-plugin, having a higher version number there would help) See [0]. I packaged Gentoo maintainers' work [1] plus cherry-picked few further changes. [0] https://wiki.mozilla.org/NPAPI [1] https://bitbucket.org/mgorny/npapi-sdk AFAICS 0.27 never changed since initial import, nor on firefox tree [2]. If Gentoo upstream was more active, they would probably bump micro version from .2 to .2+n, n is number of changes I cherry-picked. Not sure that would be really needed. [2] https://hg.mozilla.org/mozilla-central/file/75db55f6fd2c/dom/plugins/base/npapi.h#l57 At the moment in npapi-sdk-dev, mozilla-plugin.pc is just a link to npapi-sdk.pc, broken by versioned dependencies as you pointed out. Making it ship its own mozilla-plugin.pc with a higher version, yes would fix versioned deps too. IMHO patching upstream is better, just requiring more work. Anyway, it looks like both mozilla and chromium are phasing NPAPI out. https://blog.mozilla.org/security/2014/02/28/update-on-plugin-activation/ http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
