On Tue, 7 Sep 2010 10:13:15 +0100, David Goodenough <david.goodeno...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907231101.7f988...@sk2.org