Created attachment 23887 [details] show cmdline installer with GUI popup The silent install switch for both gs10010w32.exe gs10010w64.exe does not work. Because it's a NullSoft installer, it should be /S. Older versions dont have this issue.
(In reply to roy.essers from comment #0) > Created attachment 23887 [details] > show cmdline installer with GUI popup > > The silent install switch for both gs10010w32.exe gs10010w64.exe does not > work. Because it's a NullSoft installer, it should be /S. Older versions > dont have this issue. We no longer permit silent installation.
*** Bug 706496 has been marked as a duplicate of this bug. ***
(In reply to Ken Sharp from comment #1) > (In reply to roy.essers from comment #0) > > Created attachment 23887 [details] > > show cmdline installer with GUI popup > > > > The silent install switch for both gs10010w32.exe gs10010w64.exe does not > > work. Because it's a NullSoft installer, it should be /S. Older versions > > dont have this issue. > > We no longer permit silent installation. In what kind of world we don't longer permit silent installations? This will break a LOT of automated app installations. Please reconsider your decision.
Is there a compelling reason for doing so? This will make software distribution much harder.
(In reply to d.reschetow from comment #4) > Is there a compelling reason for doing so? This will make software > distribution much harder. We have encountered a great number of applications installing Ghostscript either in contravention of the AGPL or without sufficiently informing users of the fact that the application includes Ghostscript, and the user's rights under the AGPL. As a concrete example; here's a portion of the text of a recent email sent to us for support: "Ive got a massive issue with GhostScript having current exploits tied to it the issue is, I have no idea what Software uses GhostScript as a dependency/side install to figure out which vendor I need to reach out to in order to get the latest version so GhostScript is updated." If you are responsible for an application which uses Ghostscript then the only change is that your users will now see the Ghostscript installation taking place, as well as your own. We think a little kudos for us is not unreasonable, and it means that rogue applications can no longer silently install Ghostscript without informing their users and leaving them in the dark about how to replace the installed version (or who to blame when they can't). It does mean that automated Windows deployment tools for large organisation can't use our installer any more. However I question why an organisation would be installing Ghostscript on a large number of Windows PCs. It's not exactly an end-user shiny. If your application is one which is rolled out across such enterprises then yes, this will be a problem for you. This sounds like it would be commercial use, even if it is within the terms of the AGPL, so we'd probably consider it 'parasitic' and not really something we're keen to support. Finally, as one of my colleagues points out; this is open source software and you are free to alter it as you see fit, provided only that you conform to the terms of the AGPL licence. Alternatively, we offer commercial solutions and I'm sure our sales people would be delighted to field any enquiries.
(In reply to Ken Sharp from comment #5) > (In reply to d.reschetow from comment #4) > > Is there a compelling reason for doing so? This will make software > > distribution much harder. > > We have encountered a great number of applications installing Ghostscript > either in contravention of the AGPL or without sufficiently informing users > of the fact that the application includes Ghostscript, and the user's rights > under the AGPL. > > As a concrete example; here's a portion of the text of a recent email sent > to us for support: > > "Ive got a massive issue with GhostScript having current exploits tied to it > the issue is, I have no idea what Software uses GhostScript as a > dependency/side install to figure out which vendor I need to reach out to in > order to get the latest version so GhostScript is updated." > > > If you are responsible for an application which uses Ghostscript then the > only change is that your users will now see the Ghostscript installation > taking place, as well as your own. We think a little kudos for us is not > unreasonable, and it means that rogue applications can no longer silently > install Ghostscript without informing their users and leaving them in the > dark about how to replace the installed version (or who to blame when they > can't). > > It does mean that automated Windows deployment tools for large organisation > can't use our installer any more. However I question why an organisation > would be installing Ghostscript on a large number of Windows PCs. It's not > exactly an end-user shiny. > > If your application is one which is rolled out across such enterprises then > yes, this will be a problem for you. This sounds like it would be commercial > use, even if it is within the terms of the AGPL, so we'd probably consider > it 'parasitic' and not really something we're keen to support. > > > Finally, as one of my colleagues points out; this is open source software > and you are free to alter it as you see fit, provided only that you conform > to the terms of the AGPL licence. > > Alternatively, we offer commercial solutions and I'm sure our sales people > would be delighted to field any enquiries. Good position, Ken!
Gone back to 10.0 - we need silent installation on building golden master images. Hope in future releases, silent installation is possible again. THX Inga
*** Bug 706550 has been marked as a duplicate of this bug. ***
*** Bug 706592 has been marked as a duplicate of this bug. ***
I can understand the explanation and the frustration you feel because of the bad use of automated install. I want to explain you my use case. I deploy, as many schools in France, packages with wpkg in a large academic environment. We have 350+ computers, 1350+ users. And there is only one technician, not full time in the school. The install with wpkg **must** be silent as it is done with an account in background, that can not interact with the user. No user has any installation right. They go, with roaming profile from one computer to another. Only the IT guy (me) has administration rights on the machine parc. We use ghostscript with the LaTeX environment we deploy at the request of mathematics and physics teachers. The new installation scheme of Ghostscript make it uninstallable for us, and make the LaTeX installation complicated. At this time, we stay with the last version that has silent install, but it is not a good practice because we are very concerned about staying up to date for security reasons I hope my use case may make you reconsider your position. Blocking usage for illegitimate use case is absolutly right. But the usage is also blocked for legitimate use case, as our. Hoping to help
Hi! Sorry to hear you dont offer the silent switch anymore. Of course, I can fully understand your need to show people that your product is part of (probably) another isntallation. We deploy software via SCCM while the imaging process takes place with more than 2000 computers. At that stage, there is no human interaction possible. Maybe you can bring back the silant switch. But instead of showing nothing, it would be possible to display a banner screen promoting your great product while the setup runs in the background. We can deploy the software and you get your visibility.
I'm a sysadmin at a large scientific department at a University. My users make use of ghostscript as part of the normal workflow of preparing scientific documents using LaTeX and related tools, so we value being able to centrally deploy the software on a large number of workstations. On our linux computers, we "apt-get install ghostscript" (or rather, our config tools do so on our behalf), it deploys silently. On Windows, we cannot give users admin rights as that is incompatible with centrally managing a large number of consistently configured computers. Thus, we need to be able to deploy software silently and without user interaction. Unfortunately, removing the option to perform silent installations of ghostscript will not make our users give the developers (much deserved) kudos for their hard work. It will, sadly, mean we have to stop making the software available for use on Windows and try to find an alternative. Rather than requiring interaction at the point of install time, a common alternative is to permit silent deployment but pop up a per-user dialog at the point of first use saying whatever you like - whether that's "tick here to accept the licence", "thanks for your using $OUR_SOFTWARE, you can find out more about us at $URL" - and even, if it's relevant to the project, "if you like our product we'd really appreciate a donation via $URL". I would be very happy for any or all of those kinds of messages to be shown to my users when they use your software. One common method used to record this is to use a registry key such as HKCU\Software\Ghostview\EulaAccepted which is used to check/record that the first-use message has been seen.
Thank you all for your feedback, there is now a statement on the Artifex website addressing this : https://artifex.com/news/ghostscript-10.01.0-disabling-silent-install-option If I may briefly cover the additional points in comments 10 through 12: We are not 'blocking (a) legitimate use case', we are simply not offering a particular installation option. We did consider installation banners and post-installation dialogs and we discussed this with some sysadmins of our acquaintance. The idea horrified some sysadmins because their users are trained to treat unexplained dialogs and splash screens as potential infections. The only real option that seemed to be acceptable was to return to the genuinely silent installation. Apologies for the wide distribution list, I thought it worth adding to this report in case users missed the announcement on the website, and also so that searches which turned up this bug in future would be able to see the post referenced.
*** Bug 706716 has been marked as a duplicate of this bug. ***