https://bugs.winehq.org/show_bug.cgi?id=43436
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Wine-staging |Packaging Version|2.13 |unspecified Component|-unknown |wine-packages
--- Comment #1 from Michael Müller michael@fds-team.de --- The packaging files are not the reason why we stopped supporting Mageia. Their repository tools are causing the problems, otherwise everything would be ready to go.
On our build server, the packages are builtin inside of a Mageia VM and then copied to the host system, which signs the files and adds them to a repository. The problem is that the host system is running Debian and that the tool to create such repositories (genhdlist2) doesn't seem to play well with anything else than Mageia. I was unable to find a working combination of genhdlist2, URPM and librpm that works on Debian without any warnings or errors. The script also looks up files in the system to determine the Mageia version which then leads to differences in the created repository format. This will obviously not work on Debian and we therefore came to the conclusion that we can not ensure that the created repository is valid and stopped providing packages. Not to mention that Mageia also applied quite some patches on librpm and we would most probably need a second librpm version (one for Fedora and one for Mageia).
Mageia is the first distribution that caused such problems and it seems like nobody thought about the possibility that such tools might also be used on other systems. We do not really want to maintain our own forks of these libraries and it would be great if Mageia could make their packaging tools more compatible.