Re: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries
On Tue, 7 Sep 2010 10:13:15 +0100, David Goodenough
<david.goodenough@btconnect.com> wrote:
> On Tuesday 07 September 2010, Adam Borowski wrote:
> > Then, in the usual Debian parlance, "nonfree" usually suggests
> > proprietary gratis distributable things. Winetricks includes a mix of
> > distributable, non-distributable and even non-gratis software (the last
> > cathegory requires that you have a valid Windows license).
> That is not true. Winetricks is itself entirely free, and is just a simple
> script. It then downloads the other materials from public web sites,
> but by no measure can those other materials be regarded as part of
> wine-tricks - Microsoft would have something to say about that if it
> were claimed that they were part.
There are even certain winetricks commands which don't install anything at
all, they simply change settings in the given wine prefix.
(Taken in context though I don't think Adam had a significantly different
positions from yours, David; the idea here as I understand it was to package
redistributable downloads referenced by winetricks in a Debian package, which
would go into non-free to avoid having to figure out how to rebuild
everything using tools in main, but to which a "nonfree" qualifier wouldn't
be applicable.)
> On Tuesday 07 September 2010, Adam Borowski wrote:
> > In the past, there was opposition to shipping random free software for
> > Windows inside Debian, for good reasons. And since most of the rest in
> > undistributable, packaging winetrick as a big installer (in main!) is
> > probably the best idea.
I agree, I don't think it would be appropriate to try to package the
DFSG-free Windows software installable via winetricks (such as 7-zip); in any
case, packaging winetricks needn't involve shipping random free software for
Windows inside Debian.
There are other considerations which haven't been brought up in this thread
so far.
One big objection I can see is that many of winetricks's uses involve
downloading third-party software from web sites and installing it
automatically on the user's system; admittedly the user is requesting it, but
there's a good chance many users will simply be using winetricks because they
are following instructions from a forum post somewhere, so even that doesn't
necessarily mean much. (A similar argument applies to simply letting wine
download wine-gecko rather than packaging it properly in Debian.) That might
be fixable but it's a huge endeavour and it wouldn't earn us any bonus points
with upstream (I'm thinking along the lines of packaging redistributable
components properly, and stripping winetricks of references to
non-redistributable downloads - which would mean our winetricks wouldn't be
the same as upstream's, and following common instructions involving
winetricks wouldn't work in Debian).
Another objection is that providing winetricks increases the support burden;
this could be turned into an advantage (compared to users simply downloading
winetricks themselves) by adding code to (or around) winetricks so that any
changes made to wine prefixes using winetricks can be traced in bug reports.
(In a similar fashion to kernel tainting...)
winetricks also generally only works well with recent versions of wine, so
it's only really sensible to package it once we manage to keep up with wine!
(These last two are simply the first two warnings given on
http://wiki.winehq.org/winetricks .)
All this is rather negative, but I'm not sure myself whether
packaging winetricks would be a good idea or not! I do think that if it does
get packaged, it should be in its own package (since its releases aren't
synchronised with wine, as has been pointed out previously). Alternatively,
one way of "packaging" it could be to add a winetricks installer (and
updater) to the wine package...
Regards,
Stephen
Reply to: