today's git broke winetricks gecko :-(

[Vincent Povirk]

On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven <ovek at 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.

-- 
Vincent Povirk