On Thu, Feb 07, 2013 at 05:02:53PM +0200, Zeeshan Ali (Khattak) wrote: > On Tue, Jan 29, 2013 at 11:13 AM, Christophe Fergeau > <cfergeau@xxxxxxxxxx> wrote: > > On Mon, Jan 28, 2013 at 11:06:53PM +0200, Zeeshan Ali (Khattak) wrote: > >> On Mon, Jan 28, 2013 at 7:19 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > >> > On Mon, Jan 28, 2013 at 05:45:25PM +0200, Zeeshan Ali (Khattak) wrote: > >> >> On Mon, Jan 28, 2013 at 3:14 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > >> >> > You can't expect every possible Windows exe file to honour the /S switch. > >> >> > >> >> If a binary doesn't support '/S' switch, it will ignore it? > >> > > >> > Or fail saying it's an unknown parameter? > >> > >> According to Vmware docs, this is a standard MSI option: > >> > >> http://pubs.vmware.com/view-50/index.jsp?topic=/com.vmware.view.installation.doc/GUID-F19EBDF6-20A3-4A8B-95AE-786CC74F26AF.html > >> > >> If that is the case, its supposed to be guaranteed on every windows > >> installer setup app? > > > > I doubt it's guaranteed... > > Shall I believe those docs or you then? :) Something that is true for MSI installers != something that is true for all installers in the world. > Since drivers and scripts > could be changed to use .cmd without breaking API, why don't we fix > this when/if we need to. Right now we only have one driver and what we > are 100% sure is that this driver setup accepts '/S' switch and > ignores unknown switches. There is also the indication (docs I > mentioned) that we might not need this fix for any setup app at all. > > >And the way the code currently is, MSIs can't be > > installed either. > > Sorry I didn't understand this part? If you have an installer with a .msi extension, *.exe will not catch it... I don't know with what extension they are usually shipped. This *.exe can also be suboptimal for more reasons, one could also imagine situations where a .exe will be there that shall not be run (eg with unpacked drivers). Christophe
Attachment:
pgpCDLzOPiPBX.pgp
Description: PGP signature
_______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
