On Sun, 12 Sep 2021 20:54:56 +0300, Adrian Bunk <b...@debian.org> wrote: > On Sun, Sep 12, 2021 at 07:03:54PM +0200, Stephen Kitt wrote: > > On Sun, 12 Sep 2021 19:20:16 +0300, Adrian Bunk <b...@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. > > Based on the package list provided in the initial email in this thread > (and guessing the amount of transitive dependencies) I would have guessed > that there are perhaps ~ 30 packages that would have to be touched once.
... which means ~30 maintainers who need convincing individually. My experience so far is that maintainers tend not to be interested (justifiably) in Windows cross-builds. > And after that things will just continue working, just like with udebs > which are in some ways similar to what is being discussed here. udebs are mostly a packaging concern. Keeping Windows cross-builds working tends to require a bit more effort unfortunately. > > > 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. > > It is also the kind of change where it might be required that it is > fully supported in one release before it can be used by packages in the > next release, if for example any of dpkg/apt/aptitude/... in the > previous stable gives an error when seeing dependencies to another > architecture. That is indeed a good point, thanks for bringing it up! Regards, Stephen
pgp6oea3PS5Hm.pgp
Description: OpenPGP digital signature
