[pkg-wine-party] Bug#591837: Wine 1.2 packages with wine-gecko

[Ove Kaaven]

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.