On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven ovek@arcticnet.no wrote:
(It is actually for similar reasons that binaries must be buildable on a clean system (say, a build daemon), without any special (non-free) tools or sourceless libraries. Magic libshell32.a in the source package fails this requirement, and so does usage of non-free cabinet.dll to make cab file.)
I don't suppose the build could be fixed?
"The wine-gecko build is unclean" is a separate issue from "Wine-gecko should/shouldn't be a run-time requirement". Both of them are important issues, and the unclean gecko build would still be important (if not as visible) without this change.
I wouldn't expect anything less of Debian than to refuse to include wine-gecko in the free parts or as a download at startup for exactly the reasons you describe. I hope they do. These are valid concerns, and someone has to stubbornly insist that they be addressed, pointing to clear, inhuman policies.
As for the run-time requirement, I think it's good for calling attention to the fact that gecko is a requirement for a fully functional Wine (even though configure doesn't warn about it) and that "when needed" is too late, but it's absolutely useless in terms of *forcing* packagers to do anything and much more annoying than it needs to be for calling attention to the requirement.
(It also doesn't seem to actually find the .cab file, even though I'm sure I've put it in the right place, but that's a third issue that I'll have to test more carefully and possibly file a bug for.)
Providing, say, an environment variable that one could use to specify a path of the .cab would make things much less annoying for me (I'd have a work-around for the aforementioned bug-or-user-error, and I wouldn't have to copy a .cab whenever I make a new wine install in a new directory, which is fairly often.) and would make 'winetricks gecko' fixable. You'd still see the message box when invoking wine for the first time absolutely any other way, or if you do it wrong, so I don't see the problem there.
It also seems to me that a --disable-gecko-downloader configure switch that would disable the dialog COMPLETELY (even "when needed") would put gecko on equal footing with optional library requirements. It would mean: * You can warn about the perils of not having gecko at configure time. * If gecko is installed properly, it's used properly, installed at prefix creation time. * If gecko is not installed properly, programs that need it will simply fail, and you'll see an ERR in the console, as well as a nice "HTML rendering is disabled" message you wouldn't get from other components.