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

[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?

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...

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?

> Unfortunately, it seems that wine-gecko can't easily be built
> without gcc 4.5, and I'm skeptical myself about updating gcc-mingw32
> to that version for this, and if I am, I imagine the release team
> doubly so.

I can't see it happening for Squeeze, that's for sure.  For Squeeze+1
it would be nice to get the whole mingw32 situation sorted out
correctly, but I haven't contacted any of the people involved yet.

> Also, I've been busy, of course...

It happens, and it's why I'd like to be able to help out!

> >>also, there are about a thousand warnings about
> >>manpage-has-bad-whatis-entry, which is quite a nuisance and should be
> >>fixed, but that can certainly wait until after squeeze.
> >
> >That's what I thought too, they've been around for a while and are caused by
> >c2man.pl; fixing them properly isn't obvious, since the appropriate form for
> >the whatis entry uses information which isn't available in the code used to
> >generate the manpages!
> 
> There's some patch for c2man.pl in the last posting of #579890, is
> it related?

Unfortunately not - Colin's patch fixes unescaped backslashes, but
lintian generates the warning because the generated manpages have a
NAME section of the form

.SH NAME
\fBOpenColorProfileA\fR (MSCMS.@)

when it should look like

.SH NAME
OpenColorProfileA \- open a color profile

(the formatting isn't significant, lintian checks for "\-").  The
example I've picked is bad since it makes the problem look easy to fix
(reproduce the description); in many (most?) cases the description is
too long for the NAME section.

Regards,

Stephen