I would like to discuss the practice of installing additional supporting
DLLs into directories on the PATH (e.g. Perl/bin, Perl/site/bin,
Windows/System32).

I think this approach has several problems:

* You may break other applications, or be broken by other applications.
  For example I once had multiple incompatible libxml32.dll files in
  my PATH, from Perl and Ruby IIRC.

* Perl packers (PAR, PerlApp, Perl2Exe) need additional help to package
  these external dependencies, as they cannot assume every referenced
  DLL should be bundled.  But then they don't even exhaustively look at
  the import tables in the DLLs they bundle anyways.

* Installation of these DLLs is typically done by a post-install script.
  These scripts don't run properly in the GUI version of PPM if they 
  need to read from STDIN.  Additionally these files are not accounted
  for in the PPM database, so uninstalling needs to be done by a
  script too, and PPM cannot detect installation conflicts.

For these reasons the ActiveState PPM repository (and all modules bundled
with ActivePerl) typically try to use static linking, which solves all
of the issues above.  It has its own issues though:

* It requires additional disk space (and download time/bandwith)
  if the library is used multiple time (e.g. by Crypt::SSLeay and
  Net::SSLeay).

* The external library cannot be updated without updating the module
  itself.  E.g. Crypt::SSLeay needs to be re-released when there is
  a bug in OpenSSL because you cannot just replace ssleay32.dll.

* Sometimes it is hard/impossible to do static linking.  E.g. I couldn't
  get DBD-mysql compiled with VC6 to link with the mysqlclient.lib
  because the later was compiled with VC7, and compiling the MySQL client
  with VC6 is no longer supported.

A middle-way of dealing with this issue is to do dynamic linking, but
putting the additional DLLs into the same subdirectory as the module
DLL. E.g. I put libmysql.dll into auto/DBD/mysql/libmysql.dll, right
next to auto/DBD/mysql/mysql.dll.

This works well because DynaLoader will load mysql.dll with the
LOAD_WITH_ALTERED_SEARCH_PATH, which means that any additional DLLs
required my mysql.dll (like the libmysql.dll and all DLLs that it may
depend on) will be searched for in the same directory as mysql.dll
before looking anywhere else (I can't remember when we added
the LOAD_WITH_ALTERED_SEARCH_PATH functionality, but it is in
Perl 5.005, so in every version supported by PPM).

This solves some of the problems above:

* No more interference with incompatible versions on the PATH.

* Doesn't need post-install scripts.

It improves the situation for these issues:

* Users _can_ update the bundled DLLs if they know how to find
  them.

* Perl packers can figure out that all additional DLLs stored in
  the module's auto/ directory should also be packed.

It doesn't help with the additional diskspace/bandwith issue, but
I believe that the effect is so small that we can simply ignore it.

So in summary, I would like to encourage PPM repository maintainers
to use bundle additional support DLLs inside the auto/ directory
in the future.

Cheers,
-Jan 

_______________________________________________
PPM mailing list
PPM@[...].com
http://listserv.ActiveState.com/mailman/listinfo/ppm