Den 20. aug. 2010 07:38, skrev Stephen Kitt:
On Fri, Aug 20, 2010 at 07:08:21AM +0200, Ove Kaaven wrote:Den 19. aug. 2010 23:45, skrev Stephen Kitt:1. the dependency on wine-gecko really should be dropped for now (and when that package is ready, it should be at maximum a recommends since wine gets by just fine without wine-gecko). this is especially important if you want to get this into squeeze since no more new packages are going be accepted due to the freeze.Indeed, I'll remove it for now.Wine 1.2 depends on wine-gecko, it's that simple. Packaging without would be asking for RC bugs, as the result would go against Debian standards - for example, things like the security implications of automatically downloading and running untrusted binaries from the Internet with no sandboxing and no cryptographic verification of either the binaries themselves or the web server hosting the binaries.Would it be acceptable in that case to add a hash of the CAB file (as provided by upstream) to the download code, to verify it hasn't been tampered with before installing it?
I suppose you'd have to ask the people who might otherwise be filing those bugs - probably at least debian-devel. Remember that although you may be able to prevent the most practical avenue of attack by verifying that the downloaded .cab is identical to the known upstream one, for the particularly security-minded there's still the issue that the upstream .cab is, in principle, not trusted, because you can't prove what sources it was built from.
Even if you get approval, someone'd have to write the verification code. I know where the download happens, but it'll take more than an one-liner to do it, and I don't have the time. And since it's a stopgap solution, I doubt you'd receive much help from upstream.
Personally I'm rather in favour of having wine simply depend on wine-gecko, since that avoids the support problems related to Wine not installing wine-gecko when creating a new prefix; but having this dependency reduces the chances of getting Wine 1.2 into Squeeze to zero. Admittedly that may well be an argument in favour of not getting Wine 1.2 into Squeeze right there - shipping a package with known potential support issues...
I don't mind much leaving Wine 1.0 in squeeze. For those who want to run Wine 1.2 on squeeze, there'll always be www.backports.org.
Beyond getting Wine 1.2 into Squeeze though, there is an argument for having wine only recommend wine-gecko, since it is possible to create a working prefix without it, and without downloading anything either. With a recommends, most users would end up installing wine-gecko, but those with specific requirements could remove it if necessary; this to me seems desirable given the work you've done splitting wine into various packages: if a user can choose not to have libwine-openal, why not choose not to have wine-gecko, which is larger on its own than some of the wine sub-packages with their dependencies?
While you can create a prefix without, it's not supported. If you go to upstream with a problem, they'll tell you to wipe the prefix and create a new one with wine-gecko, no matter what your problem is. Supposedly a lot of things that you might not expect depends on it, actually.
One of the things about the package split is that the split packages are separable functional pieces with somewhat heavy dependency chains, which you can install at any time if you later find out you need them, hopefully without wiping your prefix. This may not be the case with wine-gecko (it wasn't, but not sure if that has changed).
Note that I got rid of the wine-utils package a while back because it offered no sensible functional split - thus, all the stuff that a regular user is likely to need (including debugger, registry editor, MSI installer, notepad, and Minesweeper), were merged into wine-bin. So, if I could choose, I'd put wine-gecko into the same category - something that probably should not be split off. The only possible argument I see for not making it mandatory is its size, and in the case of Wine, that's probably not much of an argument. At least upstream doesn't think so.