Closed Bug 104660 Opened 23 years ago Closed 14 years ago

One-step install for Windows


(Bugzilla :: Installation & Upgrading, enhancement, P3)

Windows NT





(Reporter: zach, Assigned: glob)



(Keywords: meta)


(7 obsolete files)

Tracking bug for the one-step install for NT
Blocks: 44659
Attachment #53448 - Attachment is patch: false
Keywords: meta
On Sun, Oct 14, 2001 at 12:19:20AM -0400, John Muczynski wrote:

> I've been at work on
> and
> as I'm sure you noticed.  This is in regard to installing on Windows NT.
> Question: Do you intend people installing on Windows boxes to use
> ?  (I was able to get Bugzilla 2.14 to work quite fine
> without even having to change the #! lines.  Of course I used Apache.)
> I'm thinking that your changes in the other files might require that
> be run whether a user wants to run it or not.  Perhaps that
> isn't the case.  Do you have time to comment?
> By the way, I don't know any perl, so I'm reading perldoc today.
> Kind Regards,
> -Stosh

Yes, the intention was to have all users, including Windows [NT], be
able to run the Makefile.PL for configuring and installing Bugzilla.

The way I have Makefile.PL and Bugzilla/ architected, you
should be able to use them in your DOS batch file to save you a lot
of work.  If you pre-define all the parameters in your own copy of a
Bugzilla/ file, you can run the Makefile.PL non-interactively
from the batch file and run "perl.exe Makefile.PL; make; make test;
make install; make setup".

However, please note that I have NOT tested the Makefile.PL patches
on a Windows [NT] system, so I'm not sure what pitfalls or problems
there are or that there may be.  (For example, does ActiveState Perl
come with a compatible make.exe/nmake.exe, or does the Cygwin/MS
Visual C++ environment have to be installed first?)  I doubt that I
will have the time or a Windows box to test this on, so any testing
you can do would be appreciated.
Another way to create a one-step (or at least more simple) install for
Windows users is to build an installer using something similar to
InstallShield or MSI (Microsoft System Installer) that is compatible
with the MPL.

The Apache Group now uses MSI as of apache-1.3.22.

In this way, the installer binary could be built on a "development"
machine, and end users wouldn't have to worry about having "make.exe"
and other development items installed.  (The would have to have both
Apache and ActiveState Perl installed, though.)
Although Apache supports the use of .msi files, you do have to have the correct 
version of Microsoft's MSI installed on your NT box in order to use the .msi 
file.  I'm thinking it would be easier to download the Bugzilla tarball and not 
require a .msi version of it for Windows people.

For a one step install, I'm hoping to get Apache, Perl, and Mysql installed for 
the user rather than make them do it separately.  Thus, the idea is a one step 
install; not a four step install. :-)

If running Bugzilla after 2.14 is going to require (and it sounds 
like it will require it), then perhaps I'll have to install a make if it doesn't 
come with Apache, Perl, or Mysql. 

If Bugzilla install is going to require, then I don't see using .msi 
being able to avoiding that step.  I obviously don't know enough (yet) about the 
sequence that is using.  I'll download it and start getting to 
What I meant is that if Bugzilla were packaged up in an .MSI like Apache
is now, it would make your batch file even simpler since you could simply
invoke the installers for Apache, Perl, MySQL and Bugzilla in turn.
*shrug* activestate also supports msi for windows. and i'm trying to convince 
mozilla browser to support it too. the fact that you need a certain version of 
msi doesn't bother most people, we should be able to borrow the help text from 
activestate.  As always everyone is free to use cvs checkout or sourceballs, 
but there's nothing wrong w/ offering an MSI format.
There's nothing wrong with offering an .msi
In fact, it seems that using a tarball or using an .msi would have the same 
  1. get gunzip
  2. use gunzip & pax to install tarball
  1. get correct msi
  2. use msi to install .msi
This goes the same for a zip: (self expanding or not)
  1. get unzip.exe
  2. use unzip to install .exe/.zip

I wouldn't be opposed to supporting all three formats.  It appears that 
unattended operation would be the feature to die for. :-)
MSI is probably the best solution

1. ActiveState (perl) use MSI
2. Apache use MSI
3. MSI can be used to run any "external" program (why not "perl ;-)
4. MSI in included in windows 2000/ME/XP only NT 4 and Windows 9x users need to 
manualy install the runtime
5. If you realy need you can wrap your .msi and the MSI runtime in a single 
large making your setup a real "OnStep" install

The only problem in to select the tool to generate the .msi (I only know 
comercial products)
CC writes: "MSI is probably the best solution.  ... NT 4 and Windows 9x users 
need to manualy install the runtime ... problem is to select the tool to 
generate the .msi (I only know comercial products)"

I'm thinking that using a .bat would be nice:
1. works on 9x, NT, and 2000
2. Doesn't require a manual install of a runtime
3. can be used to run any program  (perl :-)
4. a text editor is the tool to generate the .bat
5. ftp, .gz, .tar, and .zip files can be processed from a .bat
6. it might even be possible to do an unattended install of a .msi file
i'm confused, yes msi's can be linked together for package purposes. the bottom
line is there's no reason not to do an MSI in addition to whatever other silly
methods we choose to implement.

fwiw .bat's may or may not work on NT.
>the bottom line is there's no reason not to do an MSI in addition to 
>whatever other silly methods we choose to implement.
For distributing Bugzilla, yes.  But that's not what this bug's about.  What is 
the goal of this bug?  The TODO (attached above as attachment 53448 [details]) says,
Goal:   To setup up bugzilla on a Windows NT system 
        assuming that the user knows nothing and
        has nothing installed.
Is there any reason to supply more than one method of getting to that goal?
I'm hesitant to say that .msi files can't get to that goal, but they're not 
exactly popular in my neck of the woods.  To use .msi, it seems like the user 
would have to know a few non-trivial somethings rather than nothing.

>fwiw .bat's may or may not work on NT.
Um, attachment 53449 [details] [diff] [review] above is a .bat that runs on Windows NT.
Possible formats/executables that can be used on Windows NT include:
1. exe, 2. bat, 3. zip, 4. self extracting zip, 5. tar, 6. tar.gz, 
7. msi, 8. perl, 9. com, 10. cdrom autorun, 11. bootable cdrom, 
12. bootable floppy, 13. make, 14. csh scripts, 15. visual basic
(I'm probably missing a few others)

I'm ready to discount 9, 10, 11, and 12 as silly.
Of the remaining, only 1, 2, and 4 will run, given the assumption that the user 
has nothing installed.

Does anyone see any other options or do you think the goal should be different?
ok nm the .bat thing we're aiming for convenience for a system admin, not
something else (i was thinking in lockdown mode... which a system admin might
actually do considering ... ah well nm anyways)

fwiw you missed .cmd (like .bat) and .js (like .vbs).

I think we should offer .msi because it allows for very clean uninstall
procedure and at some point will be a logo requirement (it was supposed to be
for w2k...)
>Goal:   To setup up bugzilla on a Windows NT system
>        assuming that the user knows nothing and
>        has nothing installed.

A quote from Murphy's Law:

"Build a system that even a fool can use, and only a fool will use it."

Basically what I'm saying is that the installer should provide 
intelligent defaults for all options (for the user that "knows
nothing"), but allow the user with a clue to override the 
defaults, however that is accomplished with the selected
installation technology.
I like David Kilzer's point that the one-step process should make provisions for 
a user with a clue to override the defaults.  Here's a list of the defaults that 
I can think of.  Please, please, add additional ones (within the scope of this 

1. Whether to install Apache or make provisions for some other http server.
2. Whether to install ActiveState Perl, Apache/modperl, or make provisions for 
some other perl.
3. What FTP servers to get various tars from.  Whether to use tars the user has 
downloaded and where to find them.
4. What version of Bugzilla to install, where to install it, and what url prefix 
to attach it to.  Whether to uninstall earlier bugzilli, or leave them; what url 
prefix to attach them to (if left), or no url access.
5. Whether to use MySql for the database, or some other option. (I'm thinking 
future here...)
6. Whether MySql will be running on the same machine as Apache, or another 
7. Whether to uninstall packages that already exist, or to use the existing 
8. Which CPAN mirror to use to get the perl modules required by Bugzilla.
I installed InstallShield devloper 7 on my pc.

This version allow to create a msi package but allow to wrap it in diferent 

single .exe (including the msi runtime)
single .exe (with automatic download of the msi runtime if needed)
small setup.exe with download of the msi package by the exe

This is probably the best tool to use to generate an ez to user setup

Can we get some sort of milestone on this?  Thanks.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
Ready to look at, but not ready to execute.
Attachment #53449 - Attachment is obsolete: true
Summary: One-step install for NT → One-step install for Win32 (NT/2K/XP)
*** Bug 209105 has been marked as a duplicate of this bug. ***
as I have said in Bug 209105, (sorry for the dup, my search was not exhaustive 

We have to make a "double click" install for BZ.

It will further have to be hot fixable.

Our target delivery date is July 15, 2003. (Bugzilla STABLE/Tip)

We plan on using NSI, **BUT** if we can get docs on MSI asap, and the license 
issues are minimal/none we will redo in MSI. see Bug 208521
> We plan on using NSI, **BUT** if we can get docs on MSI asap, and the license 
> issues are minimal/none we will redo in MSI. see Bug 208521

Windows Installer SDK Startpage:
thanks, and the dl link is:

only works in IE, does some scripting w/ the os to dl.
This attachment is one of the files inside the .zip attachment.
Attachment #125483 - Attachment is obsolete: true

The zip was just a little bit too big to attach, so here's a url to the zip.
This will have to be a self-extracting .exe ...

the link does not work, do you have access to a site with semi-reliable 
storage? if no, we can setup a bz user for files on one of our systems.
Okay, the problem appears to be that Yahoo wants the file attached to an HTML 
before it'll allow access.  Follow this link to download the zip:

The zip contains:  perl.exe, perl56.dll,, and onestep.bat
Once I start making it as a self-extracting .exe it will be enough to bootstrap 
a system when someone double-clicks (plus or minus bugs, plus or minus 
downloads not being available because of version number changes, plus or 
minus ...)
Attachment #126995 - Attachment is obsolete: true
You'll note this is still using bugzilla 2.14.5 since 2.17 is not quite up to
speed for windows.  I've looked at 2.17.4 and it'll require a good piece of
work to get going.  I'll be approaching that later ...
Depends on: 185330
provides the latest files for onestep install (still alpha version).
This version runs on 2.17.4 but does not patch for bug 185330.
(The description for Bug 185330 has several fixes for the bug.)
provides a zip of the latest files for onestep install (still alpha version).
Today's version is
This version runs on Bugzilla 2.17.4 and does patch for bug 185330.
Attachment #129334 - Attachment is obsolete: true
Attachment #129335 - Attachment is obsolete: true
Attachment #132901 - Attachment description: Oct 8, 2002 version. This is starting to look pretty good. → Oct 8, 2003 version. This is starting to look pretty good.
Attachment #132901 - Attachment is obsolete: true
The 10-29-2003 version of the One Step Install is available as a self-
extracting executable at
(thanks Jason Pyeron)
This version ... 
... is still alpha.
... runs on Bugzilla 2.17.4 and does patch for bug 185330.
... isn't ready for Windows XP, yet; due to issues with PAX.EXE.
... is almost ready for Windows 2000.
... works on my Windows NT 4.0 box, but I haven't tested it on a different NT 
box.  I'm expecting problems with my.cnf files and database passwords.
... includes code to see if Apache is running and if the bugzilla pages are 
accessable and has a feeble attempt to bring up a browser.
can you provide a link on the site back to this bug?
just for those pesky search engines...
New version now installs with blank mysql password for 'bugs'.  I've also 
changed the password on my machine (for 'bugs' in mysql) to a blank password.
Interestingly enough, uninstalling mysql doesn't seem to erase all its 
See the  2003-11-19bugzilla_install.exe  link at
In a little while (a week or two) I'll be testing this again on Windows 2000 
and Windows XP.
New version tested on NT/2K/XP.  Seems to work except for SENDMAIL.
See the  2003-11-26bugzilla_install.exe  link at
In a little while (a week or two) I'll be working on sendmail (version 8.7 or 
I suppose you could try this version if you weren't interested in having 
bugzilla send email.  (Please send me an email if you do try it.)
> In a little while (a week or two) I'll be working on sendmail (version 8.7 or 
> better).
I've looked at email and (although its swell on the unix side) it is a bit 
lacking on the windows side.  I'm hoping the work on a few bugs gets completed 
before I try to automatically configure email on windows.  That will give me 
time to find an smtp host or something at my location.

I suppose you could try this version if you weren't interested in having 
bugzilla send email.  (Please send me an email if you do try it.)

Severity: normal → enhancement
This is sort of an outside project, so don't take the milestone literally.  I'm
just getting it off the radar for our release blockers.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Assignee: zach → johnstosh
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
Target Milestone: Bugzilla 2.22 → ---
I don't imagine anything happening on this bug, so I've reassigned it to default.

The files are still up on

Assignee: johnstosh → installation
QA Contact: mattyt-bugzilla → default-qa
Is that still something we want? If I understand correctly, this bug asks for a single .exe or .msi file which would install Perl + MySQL/PostgreSQL/Oracle + Apache + Bugzilla and configure everything for you. This sounds prone to problems to me, especially because it has to work on Windows 2000/XP/Vista + with 32 or 64 bits flavor. Max, what's your opinion?
If somebody maintains it well, or gives it to us in some way that's really easy to maintain, I'd still be happy to have it.
i'll give this one a shot, using strawberry perl, mysql, apache and nsis.
Assignee: installation → bugzilla
Summary: One-step install for Win32 (NT/2K/XP) → One-step install for Windows
Version: 2.15 → 3.4.5
I've got a script about half-way done with NSIS.  It installs PostgreSQL, Apache, and Strawberry Perl, it just doesn't do the configuring of anything yet.
i've uploaded a functional win32 installer to

remaining items:

  - configure cvs, interdiff and diff (and test)
  - add/remove programs icon
  - uninstall
  - license(s) display (MPL & GPL i guess)
  - post-install launching of browser
  - adding scheduled tasks

and of course more testing :)
Attachment #53448 - Attachment is obsolete: true
  That's so cool. Anybody else who knows NSIS: Want to look over glob's installer code? (I imagine that since it lacks an uninstall, actually testing it right now might not be feasible.)
uploaded another revision.


  - configures cvs, interdiff and diff
  - correct icon in add/remove programs
  - implemented uninstall
  - loads browser post-install
  - batch file for generating backup file
  - now using cvs stable tag instead of tarball


  - adding scheduled tasks

currently uninstall deletes the entire bugzilla directory, including the database.  much easier to implement, but i need to put a decent warning in the uninstaller prior to nuking things from orbit.
I think you can pretty much mark this FIXED. :-)
fixed :)
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.