39735 - Linux installer tarball doesn't use a subdirectory

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Mike Shaver (:shaver emeritus)]

Unpacking mozilla-i686-pc-linux-gnu-installer.tar.gz just slammed a handful of
files into my CWD.  Bad.  It should unpack into a subdir, like the non-installer
packages do.

Comment 1

[Jon Granrose]

it's done that since the beginning, but not sure what the desired behavior is.

reassigning to Samir, the linux installer guru.

Comment 2

[Samir Gehani]

OK, if you feel strongly about this nominate it for nsbeta2 and I'll fix it when 
approved.  Into the M20 bin for now.

Comment 3

[Mike Shaver (:shaver emeritus)]

Where is the Linux installer packaging kept?  Rather than tangle with PDT, I'll
fix it myself.

Comment 4

[Samir Gehani]

Ummm, under mozilla/xpinstall/packager/unix.  The subdirectory stuff would need 
modifications in three places:
1> in the *.jst files using XPInstall APIs we need to specify a target subdir
2> deliver.pl needs to be modified to tell pkgcp.pl to add a subdir (or 
post-process after pkgcp.pl has done its thing)
3> the Linux installer sources must parse for a new key (I'll have to figure out 
the key names) and use the subdir to tack on to the chosen path when creating 
new dirs in the setup type window if the default doesn't exist

I would appreciate it if you could run the diffs by me before checking them in.  
If this sounds too gunky I'll deal with it.  It's just that I need an nsbeta2+ 
bug to check in against and I'm afraid my justification for this will be weak.  
Hence, I deferred back to you for the justification.

Comment 5

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 6

[Samir Gehani]

Rescheduling to M17 since this approved for nsbeta2.

Comment 7

[Jonathan Baron]

I think this is serious, when it is combined with the absence
of instructions about what to do with the i386Installer file.
This morning I downloaded it and assumed it would run itself.
Before I knew it, I had lost write permission to all the files
in my home directory, and I couldn't log in once I logged out.
It took me half an hour to find the problem, which is that this
installer file had changed the group permission of my home
directory!  Bad bad bad!  The .tgz file worked fine.  Why is that
other one needed at all?  At least add a warning.  Jon Baron
[e-mail]

Comment 8

[Peter "jag" Annema]

Jonathan, can you tell us exactly what you did?

Were you logging in remotely, or locally?

Did you actually run it, or only unpack it?

Comment 9

[Samir Gehani]

Jonathan Baron,
The Linux installer doesn't change the permissions on any directory.  The only 
instance it sets permissions is when creating a non-existent target 
installation directory selected by the user in the folder selection dialog.  I 
would like to understand your concern.  Could you follow up with two things:
1> The exact URL of the installer you downloaded.
2> The detailed steps to reproduce teh condition you encountered.

Thank you for your time.

Comment 10

[Samir Gehani]

Fixed in ns and moz trees.

Comment 11

[Samir Gehani]

Changing QA contact to Grace.

Comment 12

[Grace Bush]

both installers inpack into subdirs with build 2000062308