MS Windows build use of versions in directory names/paths

[Raimo Niskanen]

Well, that was a long question...

Erlang comes from the Unix world, and is built for handling hot code
upgrades, so if you are a commercial customer and installs an OTP
patch, the patched application is installed in a subdirectory
with a new version number. The old version is kept in case you
would want to back out the patch later on.

That is the main reason for the version numbers on the directories.
The patch script is the same for Windows and Unix, and I guess it
is not even aware of the platform.

Large parts of OTP (at least the code server) also depends on this
directory structure. And rewriting all code would cost too much.

But, as a side note. In our internal development environment
we have a directory tree without version numbers. Version handling
is done in ClearCase. So, probably, if you would take a Windows
(or Unix) installation and strip all version suffixes from
the Erlang installation tree, and rebuild the start scripts
(the start script compiler takes an undocumented flag to 
build without version numbers) - it would work. _But_ OTP
patch handling would _not_ work, and that is why the 
installation tree does not look that way.

This is an area where Windows and Unix security approaches
still clashes head on. E.g ZoneAlarm on windows checking which 
installed program that tries to get out - that is not really
what a firewall is supposed to do. In the Unix world a firewall
is a separate box, and it checks which user and which machine
that tries to get out and knows nothing of program installation
pathes. The ZoneAlarm check is really a Worm check.

Why ejabberd uses the registry is another question. Erlang/OTP
and many others has moved away from using the registry. I think
the Erlang/OTP installer fixes the path, so if ejabberd used the
Erlang that was in the path, there would be no problem (guessing
here...)



frank@REDACTED (Frank Seesink) writes:

> I'm relatively new to Erlang, so please excuse me if this has been
> covered.  I've searched the FAQs and not found a reasoning, so thought I
> would post here.
> 
> What exactly is the reasoning behind using version numbers in the
> directory names/paths in the Windows prebuilt binaries?  That is, the
> latest version of Erlang as I write this is Erlang/OTP R10B-4 (release
> 23 Mar 2005).  Performing a vanilla/standard install, the user has
> Erland installed in
> 
> 	x:\Program Files\erl5.4.5
> 
> and there is a subdirectory
> 
> 	x:\Program Files\erl5.4.5\erts-5.4.5
> 
> Why does the Erlang development team (or the Windows installer creator)
> just install to
> 
> 	x:\Program Files\erl\
> 
> with a subdirectory
> 
> 	x:\Program Files\erl\erts
> ?
> 
> Here is why I ask.  I notice that often open source apps do this sort of
> thing, especially when they have ties to the *nix world.  I also know
> that in the *nix world, it is common to decompress appX version A.B.C in
> a directory such as ./appX-A.B.C, then create a symlink
> 
> 	./app-X -> ./appX-A.B.C
> 
> This allows the path to the application to remain constant, regardless
> of updates/changes.  If appX version A.B.D comes out, that is simply
> decompressed to its own folder and the 'app-X' symlink changed to point
> to the new version.
> 
> However, this is not how things are done typically in the Windows world.
>   I've gotten used to certain open source projects installing in a
> different directory with reach version release.  For example, the game
> BZFlag v2.0.0 installed in
> 
> 	x:\Program Files\BZFlag2.0.0
> 
> whereas BZFlag 2.0.2 installed in
> 
> 	x:\Program Files\BZFlag2.0.2
> 
> This is annoying enough, as my personal firewall rules must be adjusted
> with each release.  Average Windows users will not deal with this well,
> as it gets to be quite annoying.  But this is tolerable with games as
> you typically do not build/layer other applications on top of them.
> 
> However, programming languages like Erlang exist almost exclusively for
> just that reason:  to layer other applications on top of them.  Other
> examples might be Perl, PHP, etc.  Now in the Windows world, one of the
> most common variants of Perl is ActiveState's ActivePerl, and their
> installer by default will install Perl in
> 
> 	x:\Perl
> 
> The documentation on PHP similary advocates installing in a directory
> such as
> 
> 	x:\PHP
> 
> And with a new version release, updating is simply a matter of replacing
> the old files with the new ones in most cases (barring those users who
> heavily customize/add/change/delete files from the distribution).
> 
> The advantage of this approach is that the PATH to a given language's
> files/engine remains the same.  This makes script writing easier, not to
> mention the above firewall rule situation where you have
> application-level firewalling.  There is no "moving target" as it were.
> 
> This issue came up for me as my introduction to Erlang came from looking
> into ejabberd, the Erlang-based Jabber/XMPP server
> (http://ejabberd.jabber.ru).  Installing/running ejabberd requires
> Erlang, of course.  And the ejabberd installer offers to create a
> Windows service so that a user can run ejabberd on system startup.
> 
> However, the installation of this NT service involves launching Erlang
> and having it fire up ejabberd.  This, of course, necessitates putting
> the PATH to the current installed version of Erlang into the appropriate
> place in the Windows Registry
> (HKLM\SYSTEM\CurrentControlSet\Services\ejabberd...) where the NT
> service is set.  (Note this is not something many users will understand.)
> 
> If a new version of Windows software comes out, most people simply
> either run the latest installer on top of the old install, OR often they
> will first uninstall the old version before installing the new one.  I
> tend to do the latter so not sure how well the former might avoid this.
>   That is, if I install R10B-4 on top of R10B-3, I'm not sure if it will
> simply keep the current path or not.
> 
> But using the "uninstall, then install" approach results in a lot of
> things suddenly breaking.  The ejabberd service is no longer pointing to
> the right directory for Erlang.  Any scripts or other items which also
> required this path are also snafu'd.  Note this does NOT happen with
> updates to Perl or PHP, for example.
> 
> So I was wondering why the Erlang team chose this approach.  Noting that
> many other open source projects do NOT resort to this in Windows by
> default--e.g., Apache1/2 webservers, AWStats, Dev-PHP, Ethereal,
> FeedReader, FileZilla/Server, Neverball, OpenSSL, PuTTY, WinMerge--it
> seems it might be best NOT to put a version number in the path, but
> rather let the user find the version either by looking at a README in
> the installed directory, or in the case of Erlang, simply by running the
>   shell.  Especially noting that updating Erlang itself at present can
> result in almost ANY Erlang app breaking, and that the number of Erlang
> apps will be >= 1 (otherwise why install Erlang?), this means with each
> release of Erlang, users may have to go through and not just install the
> latest Erlang, but they will have to go adjusting any and all Erlang
> apps such as ejabberd which need the path information to work properly.
> 
> Thanks for any insight into this.  At present I resort to digging
> through the system and adjusting the path where necessary, but I can
> assure you that most Windows users will NOT do this.  The end result is
> that adoption of Erlang as a language--just as I started playing due to
> ejabberd--will be hindered as others may be frustrated/annoyed by this
> process (and I believe rightfully so).  I know the folks behind ejabberd
> swear by Erlang, and it definitely has some interesting features.  But
> even their image will be tarnished any time someone updates Erlang only
> to find that suddenly ejabberd will not run anymore.
> 
> P.S.	I tried adjusting the install path for Erlang, but the best I could
> get was
> 
> 	x:\Program Files\erl
> 
> Unfortunately, the subdirectory for ERTS is still
> 
> 	x:\Program Files\erl\erts-5.4.5
> 
> And as ejabberd uses this path, BOOM!
> 
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB