Ionen Wolkens <io...@gentoo.org> writes:
> Trying to keep Wine ebuilds in sync between wine-vanilla, wine-staging,
> and wine-proton which each have several ebuilds been giving headaches,
> and the addition of arm64 support is not helping.
>
> Goal is to offload only the gritty toolchain and slotting bits, and
> leave ebuilds to deal with normal dependencies and configure options.
>
> Could've put these in the eclass too, but it'd likely become messy as
> dependencies get added/removed between versions (want to avoid too many
> ${PV} -gt rules). Also want to avoid these to allow overlays to use
> this to package their own variants with more freedom.
>
> Note there is some difference compared to current ebuilds:
> - arm64 support using https://github.com/gentoo/gentoo/pull/41650
> as a guideline (not tested myself, pending keywording)
> - no support for non-PE builds to simplify and having less to
> test, wine-proton was already doing this to match what upstream
> Proton does
> - ^ may be a bit misleading but if USE=-mingw, will still do PE
> builds but using clang (less tested, so +mingw remains default),
> debated USE=clang and dropping USE=mingw instead but that feels
> confusing for other reasons
> - drop REQUIRED_USE that prevented USE="wow64 -mingw"
> - drop workaround that ensured man pages were installed for
> a pure (non-default) 64bit build (feels not worth it, and
> no longer needed for >=10.2)
> - no support for <wine-9 (pre --enable-archs), will likely
> drop these once they start causing problems and not worth
> extra eclass logic
> - bit of refactoring that could well be broken
>
> In the future may have the eclass handle extra things like basic tests
> too (full testsuite is nightmare), but leaving that out for now.
Just to state it explicitly: I think it's fine to go in whenever you're
happy. It's a per-package eclass and had a skim of it and it looks fine.
(Of course, if actively want input on any of it specifically, can look.)
