Hi
Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants:
eigen3 mingw-eigen3 enchant2 mingw-enchant2 freeimage mingw-freeimage gdal mingw-gdal GeographicLib mingw-GeographicLib geos mingw-geos giflib mingw-giflib gtkspell3 mingw-gtkspell3 gtkspellmm30 mingw-gtkspellmm30 jxrlib mingw-jxrlib leptonica mingw-leptonica libgeotiff mingw-libgeotiff libimagequant mingw-libimagequant libkml mingw-libkml librttopo mingw-librttopo libspatialite mingw-libspatialite libwebp mingw-libwebp openjpeg2 mingw-openjpeg2 OpenSceneGraph mingw-OpenSceneGraph osgearth mingw-osgearth podofo mingw-podofo proj mingw-proj python-pillow mingw-python-pillow qtspell mingw-qtspell shapelib mingw-shapelib svg2svgt mingw-svg2svgt tesseract mingw-tesseract uriparser mingw-uriparser
I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
On 2/20/22 3:13 PM, Sandro Mani wrote:
Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages.
What do you feel about native packages depending on MinGW packages?
Upstream wine has begun to depend on .dll files. Wine 7.3 bundles vkd3d[1][2], but will also look for it if provided with a location for the .dll files. Currently, Wine 7.2 and lower look for the native vkd3d files.
[1] https://source.winehq.org/git/vkd3d.git/ [2] https://src.fedoraproject.org/rpms/vkd3d
On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:
Hi
Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants:
Thanks for driving this idea forward, I think it'll be very good for maintainers in the long run.
I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
Seems to be a 404 - is it marked private perhaps ?
Regards, Daniel
On Mon, Mar 14, 2022 at 01:06:34PM +0000, Daniel P. Berrangé wrote:
On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:
Hi
Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants:
Thanks for driving this idea forward, I think it'll be very good for maintainers in the long run.
I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
Seems to be a 404 - is it marked private perhaps ?
Never mind, I was blinded by the other response into thinking this was a new thread, where as the orignal mail was actually weeks old.
Regards, Daniel
On 14.03.22 14:02, Michael Cronenworth wrote:
On 2/20/22 3:13 PM, Sandro Mani wrote:
Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages.
What do you feel about native packages depending on MinGW packages?
As far as I can judge, I don't see any problem.
Sandro
On 14.03.22 14:13, Daniel P. Berrangé wrote:
On Mon, Mar 14, 2022 at 01:06:34PM +0000, Daniel P. Berrangé wrote:
On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:
Hi
Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants:
Thanks for driving this idea forward, I think it'll be very good for maintainers in the long run.
I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
Seems to be a 404 - is it marked private perhaps ?
Never mind, I was blinded by the other response into thinking this was a new thread, where as the orignal mail was actually weeks old.
Right, I already went ahead and merged the work ;) So far I've not seen any side-effects directly related to unifying the two builds.
Sandro
On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:
Hi
Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants:
I've done the same with all the mingw packages I maintained just before Fedora 37 branched. So the following native packages now just contain mingw sub-RPMs:
libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
I'm so happy to have reduced this maint burden. I see a few new mingw packages pending in package review and think it'd be nice to first ask the native maintainer to consider unified package, before we approve any new separate mingw packages.
Our Mingw packaging guidelines, however, exclusively describe fully separated mingw packages. So if I suggest this to a native package maintainer who is not already familiar with mingw, they would be right to question whether this is a desirable thing.
IOW, I think we need to look at getting the mingw packaging docs updated to promote unified packaging as an officially supported (and even preferred) option, alongside separate packaging.
With regards, Daniel
-
Daniel P. Berrangé -
Michael Cronenworth -
Sandro Mani