Attached there is an ebuild for the Firefox QuakeLive Plugin required to play on http://www.quakelive.com. It depends on the eclass proposed at bug #212866. Reproducible: Always Upstream doesn't ship a chrome.manifest file. Because of that, I have to check if it exists and if it doesn't, touch the file or else the extension doesn't work. This might be true for every extension and if that's the case,this check most likely belongs to xpi_install(), but that's up to the Mozilla team to investigate.
Created attachment 201795 [details] QuakeLivePlugin-1.0.256.ebuild Needs some work on the ebuild versioning, license and dependencies.
Created attachment 201797 [details] QuakeLivePlugin-1.0.256.ebuild Obviously I'm pretty new to this and introduced a possible sandbox violation and did a wrong check on the manifest filename... This ebuild corrects both.
Requested upstream to include the chrome.manifest file. Request topic is here; http://www.quakelive.com/forum/showthread.php?p=216303
Looks like upstream does not understand your request.
Yeah, I'm guessing he didn't even read my post =P I'll keep my fingers crossed though.
It is stupid to create an ebuild for Quake Live. (It's stupid that we already have ebuilds for XPI plugins in the portage tree, but one for QL is even more stupid.) Quake Live is updating quite often, there may be security fixes out of the update schedule (tuesday is update day), sometimes even with the verison number not being incresed. The plugin url also will only provide the very latest plugin regardless of the ?v parameter. The only valid reason for an QL ebuild would be because some people may be missing x11-libs/libXxf86dga - those who do should just install it. Also: Chrome is not supported but may work by manually placing the plugin there and changing the user agent to some firefox one (so will other browsers supporting npapi plugins), if it does not work, you are on your own though.
(In reply to comment #6) > It is stupid to create an ebuild for Quake Live. (It's stupid that we already > have ebuilds for XPI plugins in the portage tree, but one for QL is even more > stupid.) > > Quake Live is updating quite often, there may be security fixes out of the > update schedule (tuesday is update day), sometimes even with the verison number > not being incresed. The plugin url also will only provide the very latest > plugin regardless of the ?v parameter. > > The only valid reason for an QL ebuild would be because some people may be > missing x11-libs/libXxf86dga - those who do should just install it. > > Also: Chrome is not supported but may work by manually placing the plugin there > and changing the user agent to some firefox one (so will other browsers > supporting npapi plugins), if it does not work, you are on your own though. It's as stupid as creating an ebuild for any extension. Since the tree provides that already, it's not stupid from the devs current standpoint. And yes, the greatest advantage of having this ebuild is handling dependency issues such as x11-libs/libXxf86dga. Saying that people "should just install it" is saying that handling dependecies in general is unnecessary. People "should just install it" for every package. And I personally don't care about chrome support, I don't know if you said that out of nothing or based in my comments about chrome.manifest. If it was the latter, this has nothing to do with Chrome.
(In reply to comment #7) > (In reply to comment #6) > It's as stupid as creating an ebuild for any extension. I have already said that. > Since the tree provides that already, it's not stupid from the devs current > standpoint. Just because the tree already includes some stupidity, that is not a valid reason to add even more. Let's use x11-plugins/noscript as an expample: If you install www-client/mozilla-firefox[restrict-javascript] it will pull in x11-plugins/noscript as POST dependencies. I don't see any andvantage in there, only disadvantages: 1. If you reinstall firefox, you need to reinstall x11-plugins/noscript as well (after firefox is installed), otherwise noscript won't work. This is a big annoyance and the user is not told to do so. 2. The ebuild has to be kept up to date, and so the version in protage is not up to date at some times - when you would just install the .xpi via firefox then firefox itself would take care of all that (and you are more up to date pluse no one needs to maintain that useless ebuild). Also speaking about stupidity, just look at the firefox ebuild and related eclasses, it's a horrible mess, done by the same people who put firefox extensions/plugins in portage. It _is_ stupid. And believe me, it WONT WORK for Quake Live because of the following reasons: 1. The plugin url will only provide the very latest plugin regardless of the ?v parameter in the URL. When Quake Live is being updated and the portage ebuild isn't (which will be the case very often, the user just gets a manifest error.) 2. After the user got that error, he opens the Quake Live website which will throw the .xpi at the users face. The user installs it because he wants to play, making the ebuild useless (in before dependencies). > And yes, the greatest advantage of having this ebuild is handling dependency > issues such as x11-libs/libXxf86dga. The very best way to do this, is to create an ebuild which will just pull the dependencies (alsa, xorg + dga lib, opengl), and NOT install anything itself - just spitting out an ewarn in the postinstall section that the the users system is now ready to install the QL plugin via the page and able play then. > And I personally don't care about chrome support, I don't know if you said that > out of nothing or based in my comments about chrome.manifest. If it was the > latter, this has nothing to do with Chrome. Sorry, I'm not into extensions, just looked that manifest thing up. (It was a misunderstanding because of TTimo's post reply.) I will forward that to the developers but it's possible that chrome.manifest is missing on puropse to disallow system wide installations or package manager inclusions.
Created attachment 201955 [details] A better way to do that. This is how I would do it.
I don't really see the point in this if each user still has to download 300MB of data files into their home directory.
Created attachment 201957 [details] Added alsa-lib dep, changed ewarn
I thought about doing that (an ebuild to handle the dependencies only). I do agree that letting Firefox manage its own extensions is better, there's nothing wrong with that, Updating extensions even work better that way. About the chrome.manifest: I highly doubt they made it like that on purpose to prevent system-wide instalations. I think they just missed it, Firefox creates that file if you don't have it. But since users don't have permission to write the file on system-wide installtions, it spits errors out.
Actulay current binary upstream version has problems with libpng14 so better to have source based one
Btw, I think Linux support was dropped for Quake Live for a while, so this is probably bogus now. Maybe close it as wonfix?
(In reply to Rodrigo Saboya from comment #14) > Btw, I think Linux support was dropped for Quake Live for a while, so this > is probably bogus now. Maybe close it as wonfix? Sadly, yes, though the browser plugin was dropped at the same time so it's doubly bogus. You have to resort to Wine now.
