From Bugzilla Helper (but I cut out the stuff that's irrelevant to this bug): From bug 42184: ------- Additional Comments From Ben Bucksch 2000-10-17 10:18 ------- Is there a commandline xpi package installer in the works? ------- Additional Comments From dveditz@netscape.com 2000-10-17 12:39 ------- Ben: please elaborate -- isn't that what the Linux installer already is? It downloads and installs .xpi files. Are you just asking for an admin-friendly "silent" mode? ------- Additional Comments From Ben Bucksch 2000-10-17 12:45 ------- dveditz, the Linux installer is an X11 app, not? ------- end of included comments ------ There is a need for a security-auditable xpinstall binary, not just for install-time (which is being handled adequately already) but for installation of plugins and additional components. I'd like, for example, to be able to do something like the following: wget http://blah.blah/foo.xpi sudo xpinstall foo.xpi This would allow site administrators to pre-install plugins for all their users, and allow users of the rpms and debs to install plugins without having to run mozilla as root. I've set Platform/OS to all/all because although this is primarily apparent on Unix, it also applies to modern windowses that are true multiuser. A case could be made that the "command line only" part isn't worth worrying about for Windows though.

command line, or nscurses?

I had imagined something like: root@mymachine:~# xpinstall foo.xpi root@mymachine:~# (looks like it doesn't even need to be linked with stdio! ;) ) If a simple approach like this above is used, it's also scripting-friendly and therefore addresses the common complaint of "what about installing mozilla on 1000 clients at once?"[1] Is there really anything in xpinstall that needs any kind of advanced prompting? [1] Note: I said common *complaint*, not common *practice*. I've seen lots of complaints about it, but never heard anything from anyone who's actually interested in doing it...

Okay, I just looked at an actual XPI file (the latest attachment to bug 87428) and it occurred to me that this could be simpler than I thought. As far as I can see, what needs to happen for xpinstall to work would be: 1) unzip the XPI file 2) put the contents in the appropriate locations 3) execute install.js, making the appropriate functions available I'm looking at this from a unix POV here because windows users may be satisfied with the existing net installer. How about something like this: #!/bin/sh # Make a temporary folder and cd to it, then do the following: unzip $1 javascript $MOZILLA_FIVE_HOME/xpinstall.js "install.js" xpinstall.js would look something like this (although a lot of this is pseudo-js, because real js doesn't have "print" or "system" as far as I know) function initInstall(name, id, ver) { print("Installing " + name + " version " + ver + "\n"); } function getFolder(folderFor) { return folderFor == "Program" ? something() : folderFor == "Chrome" ? something() : ...; } function addFile(... stuff ...) { ... stuff ... } function registerChrome(... stuff ...) { system("echo >>chrome/installed-chrome.txt \"" + ... stuff ... + "\""); } ... definitions for all the other functions in the xpinstall API... eval(readFile(ARGV[0])); This assumes a command line "javascript" program that will execute given javascript with its arguments in an ARGV array. Does such a thing exist? Also, whoever implemented this would need documentation for the full xpinstall API - is that available anywhere? I can't promise, but if it really is this easy, I may take a stab at this at some point. Is this a worthwhile approach to consider?

I believe there are other command-line install RFE's so this one may be different, but shaver at one point was going to build a command-line shim on the existing xpistub mechanism. xpistub is used by the GUI installers and has three entry points, XPI_Init, XPI_Install and XPI_Exit (or equivalent). The init funtion loads enough of XPCOM/JS/XPInstall to process local .xpi files (see the contents of xpcom.xpi), and the "install" function just takes the filename. Writing a wrapper that just takes a list of filenames (and possibly a path argument) would be laughably trivial compared to all the downloading, UI, and flexible config file processing the current install wizards do. Would that suffice? No GUI involved, but it still involves enough of a chunk of Mozilla's core that security audit concerns would still be there.

From my perspective (and I'm certainly not a security expert by any stretch) this would be fine. Even though it's not likely to happen in the near future, it's plausible (and actually, IMHO, probable, especially if XPCOM gets widely used outside of Moz) that at some point XPCOM, spidermonkey and XPInstall would get security audits. What's *un*likely is for X11 and XLib to *ever* get adequate auditing. But that's just my opinion, I could be wrong (even more than usual in this case because it's further outside my expertise than usual).

*** Bug 101067 has been marked as a duplicate of this bug. ***

*** Bug 121971 has been marked as a duplicate of this bug. ***

*** Bug 33809 has been marked as a duplicate of this bug. ***

Looks like someone's already made command-line installer, located in mozilla/xpinstall/standalone. It wasn't quite working, so I added a Makefile.in and cleaned up some stuff. It crashes at the end of the installation, but it properly installs the file you tell it to (at least, it installed the preferences bar XUL app from XulPlanet). Since I'm not that familiar with Mozilla programming, I've probably made some mistakes. For instance, I know that I shouldn't be using strtol() in Mozilla code, but I figure that this is just to get things started; also, the Makefile.in probably lists required modules that aren't really required. I'll attach the patch file, and also a tar file of the new files.

The command line xpinstall crashes before exiting, but appears to do the job.

Makefile.in probably has things listed under REQUIRES that aren't actually required.

Taking and flagging patch so I remember to review

*** Bug 131030 has been marked as a duplicate of this bug. ***

What's the status with this bug? Moz0.9.9 is long gone. Any work done? dveditz?

==> me I have a patch that needs work, but compiles and seems to work.

Comment on attachment 66657 [details] [diff] [review] Diff puts standalone client back into build, and gets the installer back to (sort of) working condition this is bitrotted

This seems to work on linux. I'd appreciate testing on other platforms (mac/win). If it builds, it will probably work. ;)

Andrew, this is something Red Hat could make use of. It seems the patch is lacking a little bit (the nsISupports impl seems screwy, we |new| but never |delete|, etc...). Do you by chance have an updated patch?

(In reply to comment #18) > Andrew, this is something Red Hat could make use of. It seems the patch is > lacking a little bit (the nsISupports impl seems screwy, we |new| but never > |delete|, etc...). Do you by chance have an updated patch? I couldn't figure out what you were talking about until I noticed I attached the wrong patch. This patch implements something along the lines of dveditz's comment 4 and is a lot simpler. The previous attempt was basically re-implementing xpistub (it would have worked, but this seems better).

Comment on attachment 159173 [details] [diff] [review] one more time Very cool. Please do not land the packaging changes at this time. Let's get it built and tested first, before we start packaging this anywhere. >Index: xpinstall/standalone/Makefile.in there's funny whitespace in this file; at least make it consistent, and preferable use spaces (except in command targets where tabs are required, of course).

> there's funny whitespace in this file; at least make it consistent, and > preferable use spaces (except in command targets where tabs are required, of > course). from other Makefiles in the mozilla tree, tabs seem to be (mostly) standard. The one included in the patch is all tabs, but the extra '+' messes up a couple of the lines. see https://bugzilla.mozilla.org/attachment.cgi?id=159173&action=diff I can replace them with spaces if you'd prefer (the file has no command targets)

Comment on attachment 159173 [details] [diff] [review] one more time sr=dveditz I don't mind including this in install packages right away, it's the trunk after all. If it's broken then fix it :-) But you'll have to convince bsmedberg

Comment on attachment 159173 [details] [diff] [review] one more time this apparently fails to build on windows. any help would be appreciated

-l<lib> doesn't work for windows, you need $(DIST)/lib/xpistub.lib instead. Looks like you'll have to handle it like ZLIB_LIBS or PNG_LIBS in configure.in and config/autoconf.mk.in Or you could do the equivalent conditionals in the local Makefile.in since no one else it likely to ever need to use xpistub.lib

found a macro that oughta do the trick

xpinstall is dead