Re: Wine MinGW system libraries
On Sun, Sep 12, 2021 at 07:03:54PM +0200, Stephen Kitt wrote:
> 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.
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.
And after that things will just continue working, just like with udebs
which are in some ways similar to what is being discussed here.
> > 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.
>...
> Regards,
>
> Stephen
cu
Adrian
Reply to: