[pkg-wine-party] Debian wine package maintenance / debian bug 479659
austinenglish at gmail.com
Tue Nov 16 06:14:49 UTC 2010
On Mon, Nov 15, 2010 at 3:21 PM, Ove Kaaven <ovek at arcticnet.no> wrote:
> Den 14. nov. 2010 00:22, skrev Austin English:
>> I'd like to take over maintaining the Debian Wine packages, presumably
>> with your mentoring/sponsoring.
> No thanks, at least not yet. As should have been apparent if you've caught
> up, I've been ready to upload new Wine releases as soon as Debian gets a
> mingw32 compiler capable of handling wine-gecko. It's not really my fault
> Debian doesn't have it yet (though I don't have the time or inclination to
> assist much with that, either).
> While help with the Wine package could be useful at some point, yet another
> person wanting to build Wine debs is the last thing that's needed right now
> (there's already a long lineup of people for that if that was the problem).
> Much more useful to work on gcc-mingw32.
>> A few starting questions:
>> Do I need a 64-bit debian machine to make the build, or will it be
>> enough to make the 32-bit packages and have the build bots take care
>> of 64 bit.
>> Same for old debian versions, will the build bots take care of this?
> I can handle the 64-bit issues. It was my plan to make the packages
> multiarch-capable, and I was well on my way, but then upstream had to go and
> make wine-gecko all but mandatory, thus causing the current problem.
Well, you could disable the wine-gecko installation prompt, relatively
easily, as a stop gap measure.
> It is my interpretation of the Debian Social Contract, Debian Policy, plus
> certain precedence-setting decisions within Debian, that installing a
> package that requires downloading a binary blob from the Internet in order
> to function acceptably and in an "upstream-supported" way, is not acceptable
> within Debian's "main" archive. (The "contrib" archive might allow it, at
> least if it could be done somewhat securely (e.g., verifying the blob using
> MD5/SHA/whatever), but then all of Wine would have to be moved there, and
> that's not really desirable.)
A related question then, since wine is at a standstill, I've started
taking a look at wine-mono, which is fairly easy to build. See
http://wiki.winehq.org/Mono. The (potential) problem is that it uses
some precompiled binaries:
to avoid having to get them compiled in mingw, which is sometimes a
pain. To meet debian policy, will these need to be built by hand? If
so, I'll start on a script to do it, and consider packaging them, a la
More information about the pkg-wine-party