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. Regards, Stephen
Attachment:
pgpHvg9PG58tP.pgp
Description: OpenPGP digital signature