Обсуждение: purpose of exe?
Hi, can you explain the purpose of the exe wrapper around the two msi files? Will there be a move away from msi files in the future?
Thanks!
-Josh
On 04/29/2015 07:08 PM, Josh Hester wrote: > Hi, can you explain the purpose of the exe wrapper around the two msi > files? Will there be a move away from msi files in the future? See here: http://www.postgresql.org/message-id/545233FC.9070502@winpg.jp > > Thanks! > > -Josh > -- Adrian Klaver adrian.klaver@aklaver.com
* Adrian Klaver wrote: > On 04/29/2015 07:08 PM, Josh Hester wrote: >> Hi, can you explain the purpose of the exe wrapper around the two msi >> files? Will there be a move away from msi files in the future? > http://www.postgresql.org/message-id/545233FC.9070502@winpg.jp That doesn't actually *explain* anything, it just states a fact with no rationale behind it. There are those of us who use some automated deployment method to install the driver; having to extract the packages from the wrapper first is just needless effort. Yes, in principle I can deploy the wrapper executable. Except if I want to apply an external transform to the package, which I do. There may actually be some software in the world where MSI simply can't do the job. I have a hard time believing that an ODBC driver that drops maybe ten files and the same number of registry keys belongs in that category. I have no objection to that wrapper existing, I just don't want to use it. Please provide the individual MSIs as well. -- Christian
On 04/30/2015 07:15 PM, Christian Ullrich wrote: > * Adrian Klaver wrote: > >> On 04/29/2015 07:08 PM, Josh Hester wrote: >>> Hi, can you explain the purpose of the exe wrapper around the two msi >>> files? Will there be a move away from msi files in the future? > >> http://www.postgresql.org/message-id/545233FC.9070502@winpg.jp > > That doesn't actually *explain* anything, it just states a fact with no > rationale behind it. Pretty sure the below is an explanation: "New Windows installer installs both 32-bit and 64-bit driver at once on 64-bit OS. Both drivers may be needed on 64-bit OS because 32-bit applications require 32-bit driver and 64-bit applications require 64-bit driver. " Having seen enough posts on this list from folks wondering why their 32 bit apps could not find a driver on a 64 bit machine I understand the reasoning. > > There are those of us who use some automated deployment method to > install the driver; having to extract the packages from the wrapper > first is just needless effort. That is entirely possible, I don't play enough in the Windows world to know. > > Yes, in principle I can deploy the wrapper executable. Except if I want > to apply an external transform to the package, which I do. > > There may actually be some software in the world where MSI simply can't > do the job. I have a hard time believing that an ODBC driver that drops > maybe ten files and the same number of registry keys belongs in that > category. > > I have no objection to that wrapper existing, I just don't want to use > it. Please provide the individual MSIs as well. That is for a developer to answer. I am just a user. > -- Adrian Klaver adrian.klaver@aklaver.com
Christian Ullrich wrote: > * Adrian Klaver wrote: > >> On 04/29/2015 07:08 PM, Josh Hester wrote: >>> Hi, can you explain the purpose of the exe wrapper around the two msi >>> files? Will there be a move away from msi files in the future? > >> http://www.postgresql.org/message-id/545233FC.9070502@winpg.jp > > That doesn't actually *explain* anything, it just states a fact with no > rationale behind it. > > There are those of us who use some automated deployment method to > install the driver; having to extract the packages from the wrapper > first is just needless effort. > > Yes, in principle I can deploy the wrapper executable. Except if I want > to apply an external transform to the package, which I do. > > There may actually be some software in the world where MSI simply can't > do the job. I have a hard time believing that an ODBC driver that drops > maybe ten files and the same number of registry keys belongs in that > category. > > I have no objection to that wrapper existing, I just don't want to use > it. Please provide the individual MSIs as well. I agree. There's a perennial problem where software is OK for some older version of OS, but the installer quite simply won't run on it. Adding an extra layer is highly undesirable. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
On 1 May 2015 at 10:15, Christian Ullrich <chris@chrullrich.net> wrote: > * Adrian Klaver wrote: > >> On 04/29/2015 07:08 PM, Josh Hester wrote: >>> >>> Hi, can you explain the purpose of the exe wrapper around the two msi >>> files? Will there be a move away from msi files in the future? > > >> http://www.postgresql.org/message-id/545233FC.9070502@winpg.jp > > > That doesn't actually *explain* anything, it just states a fact with no > rationale behind it. > > There are those of us who use some automated deployment method to install > the driver; having to extract the packages from the wrapper first is just > needless effort. > > Yes, in principle I can deploy the wrapper executable. Except if I want to > apply an external transform to the package, which I do. > > There may actually be some software in the world where MSI simply can't do > the job. I have a hard time believing that an ODBC driver that drops maybe > ten files and the same number of registry keys belongs in that category. > > I have no objection to that wrapper existing, I just don't want to use it. > Please provide the individual MSIs as well. Strong agreement on that point - the individual MSI files should be published, or trivially extractable from the bundle installer. I think the latter would keep things simpler for most users while still making easy MSI modifications, AD deployments, etc practical. A quick look at the bundle suggests that the installer wrapper should support the /layout option to unpack the bundle contents... but there's no indication where they go, and the installer simply says "Setup successful" after run with /layout . It doesn't seem to spit anything out into %TEMP% or the directory it's run from, and the WiX installer logs in %TEMP% suggest it might just be running an install as if /layout was not specified. A bit of searching shows that /layout doesn't extract the contents: http://stackoverflow.com/q/16219706/398670 . So it's not what's needed. The installer setup program is a WiX bundle: http://wixtoolset.org/documentation/manual/v3/bundle/, http://wixtoolset.org/documentation/manual/v3/xsd/wix/bundle.html . The sources are in the main psqlODBC tree, under installer/psqlodbc-setup/ . Since there's no /extract flag or similar, until/unless one gets added you can extract a bundle by installing the WiX toolkit then using: dark -x . the_bundle.exe which will emit the MSIs in a directory named AttachedContainer /. Clumsy, to be sure, but it'll work. There's a WiX feature request to add self-extract support; see http://wixtoolset.org/issues/3659/ . In the mean time we could support it if we used a custom bundler application, but I don't expect anyone will be leaping for the chance to do that... This might be interesting if anyone does land up interested: http://www.wrightfully.com/extracting-wix-bundled-msi-files-without-running-the-installer/ . It's focused on unpacking the MSIs but in the process shows how to unbundle them. On a side note, the README that's zipped with the bundler doesn't explain that both the 32-bit and 64-bit drivers are included, which would be helpful. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services