[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wine MinGW system libraries

On Sun, 12 Sep 2021 19:20:16 +0300, Adrian Bunk <bunk@debian.org> wrote:
> On Sun, Sep 12, 2021 at 05:31:41PM +0200, Stephen Kitt wrote:
> >...
> > While one could imagine adding support to all the appropriate
> > source packages to build similar “Architecture: all” packages, that would
> > require convincing all the relevant maintainers,  
> Adding a new release architecture (partial or not) requires convincing 
> the ftp team and the release team.
> It would also require many software changes.

Yes, it would. However, it requires convincing a well-defined set of people
*once*. If we handle Windows dependencies using “Architecture: all” packages,
we would either end up with something like Fedora’s MinGW-w64 SIG (with a
complete set of independent packages), or we would end up having to convince
a huge set of package maintainers over and over again.

> How would for example the dependencies of wine:amd64 be fulfilled?
> Just supporting that package dependencies might only be fulfilled by 
> also using packages from a different architecture would require changes 
> in many places, like for example the testing migration scripts that 
> ensure installability after migration.

In the same way as the none-arch packages would be. Yes, it’s a lot of work,
but it’s useful for more than just Wine, and it can be done once for all the
interested architectures.

> > and it would end up tying the testing migrations to MinGW-w64...  
> If this partial arch (and Wine) should be part of Debian releases,
> then testing migrations would have to be tied to it in any case.

True, I’d missed that. (In my mind I was comparing this with having separate
source packages.)

> >...
> > The buildd situation isn’t necessarily that much of an obstacle: it seems
> > to me we could have “Windows” buildds which are really Linux amd64
> > systems, that cross-build for Windows.  
> The first obstacle is that if you want to be the first who does cross 
> building packages on the buildds, there is likely a lot of work and 
> bugfixing ahead for you for getting that working.

A lot of that work has already been done for http://crossqa.debian.net/

Fixing this would reduce the burden on all the maintainers who currently
handle cross-built packages in the archive, so overall I think it would be a
net win.



Attachment: pgpHvg9PG58tP.pgp
Description: OpenPGP digital signature

Reply to: