Closed Bug 572405 Opened 10 years ago Closed 6 years ago

Installer should read defaults from a setup.ini file

Categories

(Firefox :: Installer, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mkaply, Assigned: mkaply)

Details

Attachments

(1 file, 1 obsolete file)

Attached file Read checkboxes from built in INI file (obsolete) —
It would be nice for creating custom installers if the defaults for the various checkboxes could be read from an INI file that was contained in the install versus specifying on the command line.

Also these defaults would be used by the wizard.

The patch attached does just that.

It checks for a file called setup.ini and if found, reads the default values for the checkboxes from that file.

In order to do this, I had to change installer.ini so that it uses those variables when writing the INI files used by the various pages.

Note I did not add support for everything in the INI file into the setup.ini file.

For my purposes, I didn't need everything. This could be done trivially.
Attachment #451585 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 451585 [details]
Read checkboxes from built in INI file

I'm fine with this with the following changes... will still need to review after the changes have been made.

1. It should use the setup.ini in the distributions directory that is currently used for branding instead of another ini file.

2. Check for the /INI command line argument (it should override the setup.ini) and if not present then check for the existence of the distributions\setup.ini. Set a var to the ini file and use the same ReadINIStr calls.

3. I'd prefer not having the option to set as the default browser when running silent since there will most likely be admins that *think* it should set it as the default for the users of the system instead of the account they are using to install with. I can get over that and just document this fact.
Where is the distributions directory in an unpacked build? It is at the same level as localized/nonlocalized/optional?

Or is it in one of the subdirectories?

Thanks
I apologize if I screwed up tabs in this file. It appears to use a mix of tabs and spaces.

In my new code, I used two space indentation.
Attachment #451585 - Attachment is obsolete: true
Also, where is the documentation on what can be in the setup.ini used by the installer? I'm modifying the installer files directly and would love to find another way.
(In reply to comment #4)
> Created an attachment (id=451605) [details]
> Use INI command line if present
> 
> I apologize if I screwed up tabs in this file. It appears to use a mix of tabs
> and spaces.
> 
> In my new code, I used two space indentation.
Just did a search of common.nsh and there isn't a single tab in the file so it must be something you did to your source.

The setup.ini was requested for distributions and it never went anywhere hence no docs... take a look at the SetBrandNameVars in common.nsh for more info.

You can also change the images in the installer... take a look at the preWelcome and preOptions functions in installer.nsi
OK, looking again, I think that patch is good. The whitespace movement is just due to indentation movement because of the nested ifs.

Would you rather see a patch with no whitespace at all?
I can manage... just to set expectations, I should be able to get to the review by next week.
Attachment #451605 - Flags: review?(robert.bugzilla)
FYI, I'm not rushed on this. I'm having to build the installer custom for my purposes anyway.
Forgot about this one. Any chance of this making FF4?
Robert, any time to look at this?
Robert, any time for this?
(Robert wasn't CC'd)
Assignee: nobody → mozilla
Curious if there were any updates on this? It appears that there is a fix available, just waiting to be committed. 

Thanks in advance.
Flags: needinfo?(robert.strong.bugs)
Comment on attachment 451605 [details] [diff] [review]
Use INI command line if present

(In reply to John from comment #14)
> Curious if there were any updates on this? It appears that there is a fix
> available, just waiting to be committed. 
> 
> Thanks in advance.
The porting of the stub installer code to the complete installer takes precedence over this and this patch will likely make that work more complicated.

Besides mkaply, how many people really want the ability to specify the defaults during a non-administrative install? What is the use case.

minusing for some obvious formatting errors.
Flags: needinfo?(robert.strong.bugs)
Attachment #451605 - Flags: review?(robert.strong.bugs) → review-
This was requested by some enterprises because our installer isn't easily customizable. This would allow them to customize any of our installs.

But that was a long time ago. I think by this point, most enterprises have given up on using our installer.
Flags: needinfo?(mozilla)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.