These are self-extracting .exe files that contain the One Step Install
for Bugzilla
2003-10-29bugzilla_install.exe
2003-11-12bugzilla_install.exe
2003-11-19bugzilla_install.exe
2003-11-26bugzilla_install.exe
------- Additional Comment #2 From John Stosh Muczynski 2001-10-13 21:13
-------
Created an attachment (id=53449)
prototype of "One Step" Install for Windows NT
------- Additional Comment #3 From David D. Kilzer (ddk) 2001-10-15 09:46 -------
On Sun, Oct 14, 2001 at 12:19:20AM -0400, John Muczynski wrote:
> I've been at work on
> http://bugzilla.mozilla.org/show_bug.cgi?id=44659
> and
> http://bugzilla.mozilla.org/show_bug.cgi?id=104660
> 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
> Makefile.pl ? (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
> Makefile.pl 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/Config.pm 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/Config.pm 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.
------- Additional Comment #4 From David D. Kilzer (ddk) 2001-10-15
10:24 -------
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.
http://www.installshield.com/
http://www.microsoft.com/downloads/release.asp?releaseid=32832&NewList=1
http://www.microsoft.com/downloads/release.asp?ReleaseID=32831
The Apache Group now uses MSI as of apache-1.3.22.
http://httpd.apache.org/dist/httpd/binaries/win32/
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.)
------- Additional Comment #5 From John Stosh Muczynski 2001-10-15 14:09
-------
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 Makefile.pl (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 Makefile.pl, then I don't see
using .msi
being able to avoiding that step. I obviously don't know enough
(yet) about the
sequence that Makefile.pl is using. I'll download it and start
getting to
work...
------- Additional Comment #6 From David D. Kilzer (ddk) 2001-10-15
14:33 -------
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.
------- Additional Comment #7 From timeless@myrealbox.com 2001-10-15
20:46 -------
*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.
------- Additional Comment #8 From John Stosh Muczynski 2001-10-16 05:39
-------
There's nothing wrong with offering an .msi
In fact, it seems that using a tarball or using an .msi would have
the same
steps.
TARBALL
1. get gunzip
2. use gunzip & pax to install tarball
MSI
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. :-)
------- Additional Comment #9 From Cedric Caron 2001-10-25 00:56 -------
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 makefile.pl
;-)
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)
------- Additional Comment #10 From John Stosh Muczynski 2001-10-25
17:01 -------
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 onestep.pl :-)
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
------- Additional Comment #11 From timeless@myrealbox.com 2001-10-25
17:39 -------
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.
------- Additional Comment #12 From John Stosh Muczynski 2001-10-25
18:39 -------
>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) 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 above is a .bat that runs on Windows NT.
------- Additional Comment #13 From John Stosh Muczynski 2001-10-25
18:50 -------
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?
------- Additional Comment #14 From timeless@myrealbox.com 2001-10-25
20:09 -------
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...)
------- Additional Comment #15 From David D. Kilzer (ddk) 2001-10-26
08:38 -------
>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.
------- Additional Comment #16 From John Stosh Muczynski 2001-10-26
10:41 -------
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
bug).
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
machine.
7. Whether to uninstall packages that already exist, or to use the
existing
files.
8. Which CPAN mirror to use to get the perl modules required by Bugzilla.
------- Additional Comment #17 From Cedric Caron 2001-11-01 14:33 -------
I installed InstallShield devloper 7 on my pc.
This version allow to create a msi package but allow to wrap it in diferent
format:
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
------- Additional Comment #18 From Matthew Tuck 2001-11-09 08:48 -------
Can we get some sort of milestone on this? Thanks.
------- Additional Comment #19 From John Stosh Muczynski 2003-06-11
19:18 -------
Created an attachment (id=125483)
perl script wrapped inside a .bat header -- alpha version of one step
install
Ready to look at, but not ready to execute.
------- Additional Comment #20 From Dave Miller 2003-06-11 19:24 -------
*** Bug 209105 has been marked as a duplicate of this bug. ***
------- Additional Comment #21 From Jason Pyeron 2003-06-11 21:39 -------
as I have said in Bug 209105, (sorry for the dup, my search was not
exhaustive
enough):
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
------- Additional Comment #22 From Harri Vartiainen 2003-06-11 22:22
-------
> 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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/about_windows_installer.asp
------- Additional Comment #23 From Jason Pyeron 2003-06-11 22:54 -------
thanks, and the dl link is:
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
only works in IE, does some scripting w/ the os to dl.
------- Additional Comment #24 From John Stosh Muczynski 2003-07-03
05:29 -------
Created an attachment (id=126995)
perl script wrapped inside a .bat header -- alpha version of one step
install
This attachment is one of the files inside the .zip attachment.
------- Additional Comment #25 From John Stosh Muczynski 2003-07-03
20:37 -------
http://www.geocities.com/johnstosh/2003-07bugzilla_install.zip
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 ...
http://www.geocities.com/johnstosh/2003-07bugzilla_install.zip
------- Additional Comment #26 From Jason Pyeron 2003-07-09 16:59 -------
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.
------- Additional Comment #27 From John Stosh Muczynski 2003-07-23
19:02 -------
http://www.geocities.com/johnstosh/
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:
http://www.geocities.com/johnstosh/
The zip contains: perl.exe, perl56.dll, onestepmodules.pl, 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 ...)
------- Additional Comment #28 From John Stosh Muczynski 2003-08-06
18:47 -------
Created an attachment (id=129334)
2003-Aug-6 onestep.bat (still alpha version)
------- Additional Comment #29 From John Stosh Muczynski 2003-08-06
18:50 -------
Created an attachment (id=129335)
2003-Aug-6 onestepmodules.pl (still alpha version)
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 ...
------- Additional Comment #30 From John Stosh Muczynski 2003-09-24
18:54 -------
Also,
http://www.geocities.com/johnstosh/
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.)
------- Additional Comment #31 From John Stosh Muczynski 2003-10-08
19:12 -------
Created an attachment (id=132901)
Oct 8, 2002 version. This is starting to look pretty good.
http://www.geocities.com/johnstosh/
provides a zip of the latest files for onestep install (still alpha
version).
Today's version is 2003-10-08bugzilla_install.zip
This version runs on Bugzilla 2.17.4 and does patch for bug 185330.
------- Additional Comment #32 From John Stosh Muczynski 2003-10-29
19:04 -------
The 10-29-2003 version of the One Step Install is available as a self-
extracting executable at
http://johnstosh.public.pyerotechnics.com
(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.
------- Additional Comment #33 From Jason Pyeron 2003-10-29 20:22 -------
can you provide a link on the site back to this bug?
just for those pesky search engines...