Guten Tag Kristis Makris,
am Donnerstag, 13. Dezember 2007 um 20:03 schrieben Sie:

> Exactly. We need to dynamically do it, along with "other things". That's
> really the issue:

> http://bugzilla.mkgnu.net/show_bug.cgi?id=831#c1

Let's identify the problems in this case: You provide a zip with
absolute paths because those paths are needed in the codebase. This
results in problems for people who don't use your zip-coded absolute
path because they have to edit the codebase using the proper paths of
their installation and it results that the zip-coded path is just
valid for a small amount of Windows installations out there.

1. How ca we provide a way to let the user easily define the
installation directory?

This is not a problem at all, I think. At least for building MSI
Package there is an excellent toolkit out there called WiX (Windows
Installer XML for the germans out there ;-)) with a tool called tallow
wich will do the main work in building an installer for you.

http://www.tramontana.co.hu/wix/

WiX provides a standard GUI with license agreement, customizing the
installation, components, paths and so on, tallow will build the
needed XML-code for the MSI-package for every file in the
SCMBug-directory automatically. I used it recently in one project and
found it to be very comfortable. It's capable of writing XML-files and
registry entries, executing other programs and so on.

In my oppinion with this approach we could provide a easy way to let
the user choose the installation directory while respecting the Windows
guidelines for deploying software, I think we could install a service
for SCMBug using srvany, I use it since the beginning of using SCMBug
without any problems, and I even think we could generate the templates
for hooks and stuff like that using some other program or simple batch
file or something like that after the installer finished.

Using the easy way installing the service is just execution of the
following command line and setting some registry entries:

sc create SCMBug DisplayName= SCMBug binPath= srvany.exe start= auto

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCMBug]
"Description"="SCMBug für Subversion"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCMBug\Parameters]
"Application"="C:\\\\Programme\\\\Perl\\\\bin\\\\perl.exe 
\"C:\\\\Programme\\\\Scmbug\\\\sbin\\\\scmbug_daemon.pl\" 
\"C:\\\\Programme\\\\Scmbug\\\\etc\\\\scmbug\\\\daemon.conf\""

2. In which places of the codebase this installation directory is
needed and can't be worked around?

We have writing the pid, use lib, some files for VDD generator for
example and so on. The pid could be written to %TEMP%\SCMBug\PID in my
oppinion, the lib-path of SCMBug could be added to Windows-PATH due to
an installation. Wouldn't use lib even work with relative paths?
Something like use lib "../share/scmbug/lib/"; instead of use lib
"C:/Programme/Scmbug/share/scmbug/lib/"; in
SCMBug/bin/scmbug_install_glue.pl. At my company we use a perl package
setting library paths for perl modules which will be included in every
.pl-files BEGIN-statement and reads a configuration file in the same
directory where include-directories are specified. This could be
generated by the installer, I think, by using "echo" at the command
line maybe.

$arguments->{ stylesheet_file } = "C:/Program 
Files/Scmbug/share/scmbug/glue/templates/stylesheets/vdd.xsl";

Could code like this be changed to use a configuration setting or some
kind of environment variable?

3. Identifying any other places needing this installation directory
for proper working.

I did never use the SCMBug-installation mechanism for glues, what
information is needed for this to work? It needs the perl-installation
directory in the hooks templates which could be read from registry
with the installer, I think. Should the hooks be generated along with
the installation directory in some kind of way, maybe just be echo'ing
the content to a file using pipes?

> I have so far refused to expect from the user to execute a .bat file
> that will take care of this.

Bugzilla comes with checksetup.pl and it seems to work... Though, I
like just decompressing a zip or checking out from version control and
let TextPad do the rest.

> I'd rather we had a proper installer that
> can be built under Linux.

Is this necessary? Windows software should use MSI, in my oppinion,
it provides a lot of things one would otherwise has to reimplement or
something like that, it could make administrators life very easy by
using WSUS etc. Windows software is often deployed in one directory,
that's often not the case with linux. Maybe it's the better approach
to seperate the installers and use the secific advantages on both
target platforms, which would make it even easier respecting some
special guidelines.

> If we were to fix all this, I'd rather we had an installer,
> so the user "double-clicks" and everything is setup. Including a Windows
> daemon service:

> http://bugzilla.mkgnu.net/show_bug.cgi?id=635

At least copying the files to a user defined directory shouldn't be
any real horror using WiX. I could provide a demo over weekend, I
thnk.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  [EMAIL PROTECTED]
Web:     http://www.am-soft.de

AM-SoFT Potsdam GmbH, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 12480, Geschäftsführer Andreas Muchow

_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users

Reply via email to