Re: today's git broke winetricks gecko :-(
2009/11/17 Juan Lang <juan.lang(a)gmail.com>:
If a previously-optional component is now deemed to be mandatory, and that component *on its own* happens to double the download size required to install Wine, I consider that a problem. Not everyone has a cable or ADSL2+ connection.
Yes, but it's not updated as frequently.
What guarantee is there of this in the future? In fact, if you can guarantee that there will never be another update to Gecko, then the argument on the size of Gecko disappears.
The development version of Wine is updated roughly every two weeks, so if a user is willing to download a development version approximately that often, why should a single, equally sized download be an impediment?
Gecko is not a core part of Wine. It is only needed for an MSHTML implementation. There are plenty of apps in existence that do not and will not have any use for Gecko. I argue that the size of Gecko is a good reason to not require it to be installed for those users who *know* they don't need it.
wine cmd /c echo yes now downloads gecko. How can you possibly justify this?
Is this to me? I didn't say that.
No, you didn't. But how can you support a scheme where running "wine cmd /c echo yes" prompts for Gecko download? 2009/11/17 Marcus Meissner <marcus(a)jet.franken.de>:
On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote:
You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
I btw thought of actually building wine-gecko using mingw instead of just distributing the .cab.
Just did not have the time to try it in the .spec file.
This is also the 1 problem I see with distro inclusion here, so far I just have it in my openSUSE buildservice repos.
If Gecko is to be included as a requirement in the current fassion, I argue that it should be made packageable/installable from wine-git. I support Vincent's suggestion of "--disable-gecko-downloader", and would also like to see "--enable-gecko"/"--disable-gecko" to build the .cab file (on "make") and install it to the correct location (on "make install"). Or perhaps, a "make gecko"/"make install-gecko" pair (which would be more convenient for me as a package maintainer).
Ben Klein <shacklein(a)gmail.com> writes:
2009/11/17 Juan Lang <juan.lang(a)gmail.com>:
If a previously-optional component is now deemed to be mandatory, and that component *on its own* happens to double the download size required to install Wine, I consider that a problem. Not everyone has a cable or ADSL2+ connection.
Yes, but it's not updated as frequently.
What guarantee is there of this in the future? In fact, if you can guarantee that there will never be another update to Gecko, then the argument on the size of Gecko disappears.
Obviously there will be some updates, and obviously they are not as frequent as Wine releases. Since Gecko was added there have been 3 updates, for 56 Wine releases in the same period. The download size is not a valid argument.
wine cmd /c echo yes now downloads gecko. How can you possibly justify this?
Is this to me? I didn't say that.
No, you didn't. But how can you support a scheme where running "wine cmd /c echo yes" prompts for Gecko download?
It's not running cmd that needs it, it's creating a new functional Wine prefix. Like it or not, there are many things that need to be part of a proper Windows environment, and we can't predict which will be needed, or install everything on demand. That's not how Windows works. Yes, the download dialog is annoying, but once most packages do the right thing we can take it down and put up a "mshtml support broken, complain to your packager" dialog box instead. -- Alexandre Julliard julliard(a)winehq.org
There is one point in this discussion that I've been asking myself: Why does Wine need a Windows Gecko instead of a native (Unix/Linux) one? And if the question before makes any sense, wouldn't a native version be part of a firefox package and thus not need extra packaging? I'm sorry to ask such a simple question, but it's a long time that I've had any insight into the Wine details. Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
2009/11/17 Joerg Mayer <jmayer(a)loplof.de>:
There is one point in this discussion that I've been asking myself: Why does Wine need a Windows Gecko instead of a native (Unix/Linux) one? And if the question before makes any sense, wouldn't a native
I'd guess to allow it to interact with Win32 windows etc. instead of having to get e.g. an X window from somewhere to render to, since only winex11.drv should know about those.
Gecko is not a core part of Wine. It is only needed for an MSHTML implementation. There are plenty of apps in existence that do not and will not have any use for Gecko. I argue that the size of Gecko is a good reason to not require it to be installed for those users who *know* they don't need it.
How do they know that? Things show up in surprising places, and we don't always know why it is that an app is failing.
No, you didn't. But how can you support a scheme where running "wine cmd /c echo yes" prompts for Gecko download?
I never said whether I support it or not. I was annoyed that you were making specious arguments. You're doing it again, by assuming I have a particular position. I'm saying, it's worth listening to Jacek's (and now Alexandre's) positions. --Juan
participants (5)
-
Alexandre Julliard -
Ben Klein -
Henri Verbeet -
Joerg Mayer -
Juan Lang