Closed Bug 105679 Opened 23 years ago Closed 23 years ago

Must surf as root for XPinstall under Linux

Categories

(SeaMonkey :: Installer, defect)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: lemire, Assigned: slogan)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 BuildID: 2001101201 Say I want to install multizilla under Linux. I visit multizilla.mozdev.org as a user (of course, since I don't surf as root!). I then click on the proper link having "software installation" enabled. It will then download the package and say *nothing*. In effect, the package never gets installed and I'm not even sure it was ever saved to disk. Reproducible: Always Steps to Reproduce: 1. Install Sun's JVM under Linux (rpm -ivh j2sdk-1_4_0-beta2-linux-i386.rpm for example) 2. You can verify that a mozilla-compatible plugin is available under /usr/java/j2sdk1.4.0/jre/plugin/i386 1. Install mozilla under Linux. 2. Visit a page like http://multizilla.mozdev.org/installation.html where you can install a component. (Surf as a user, not as root!) 3. Click on the proper link, wait till the download is done. Actual Results: You receive no error message. The package was never installed. Expected Results: The package should get installed if only in user space (under $HOME/.mozilla). At the very least, a proper error message should pop up saying that you can't install components as a user (please give the warning *before* the download!). I don't see why you expect people to surf as root??? That's not a good practice. You could allow root to disable software installation for all users. Workaround: quit mozilla, log on as root, visit the web page, install the package, quit mozilla, log on as user and use package. In effect, this forces you to surf as root for some time. I don't see how it can be considered a good thing!
Status: UNCONFIRMED → NEW
Ever confirmed: true
dupl bug 41057? According to dveditz@netscape.com in that bug, it's the job of the XPInstall JS to put files into the Profile directory instead of the Chrome directory. If that's true, then the bug is actually in the XPI file, not Mozilla.
There are more specific bugs of which this is a duplicate, I just haven't dug them out yet. Mostly this is a script problem in the particular scripts being installed (thus INVALID), though it could perhaps be considered a DUPLICATE of the feature request for an error alert at the end of the install. The "install java" steps confuse me, I'm not sure how they're relevant here. Java is a special case in that it probably doesn't work if not installed in the correct place, and in order to install you will have to have write privileges into the Mozilla plugins directory (please, not "root" -- you should have a "bin" user with privileges to write to the system applications area). I'm picking the INVALID (bad script) part because I'm too swamped to hunt down the relevant duplicates. Bug 41057 is too general though.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
duplicate of bug 29741 ?
Verified invalid
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Component: Installer: XPI Packages → Installer
QA Contact: ktrina → general
You need to log in before you can comment on or make changes to this bug.