All of the non-intentional differences between win32 and win64
packages are gone now, so it should be easier to compare the two
repositories now.
2011/4/15 Fridrich Strba
On 15/04/11 16:38, Maarten Bosmans wrote:
Real differences in packaging that are correct, e.g. --- windows:mingw:win32/mingwXX-glib2/mingwXX-glib2.spec 2011-04-13 16:54:02.556618000 +0200 +++ windows:mingw:win64/mingwXX-glib2/mingwXX-glib2.spec 2011-04-13 16:53:58.084618000 +0200 -%{_mingwXX_bindir}/gspawn-win32-helper.exe +%{_mingwXX_bindir}/gspawn-win64-helper.exe
Yup, these are correct and complicate somehow my synchronization process.
I have changed those to %{_mingwXX_bindir}/gspawn-*-helper.exe So the glib2 packages are the same again.
Is there some (semi-)automated way to keep the packages in both repositories synchronized? That would prevent a lot of these little mistakes. (In general I'm quite unaware of what the workflow is to get both win32 and win64 packages. I only submit mingw32 requests and let Fridrich handle the rest.)
Typically I do following after accepting your request:
1) in the corresponding windows:mingw:win32 repository and corresponding mingw32-<package>, I do "osc update" which will bring the revision on the version of the accepted commit. I see the version as N.
2) I diff the change, modify the diff and test-apply to the corresponding mingw64-<package> "osc diff -r<N-1> | sed 's#mingw32#mingw64#' | sed 's#MINGW32#MINGW64#g' | (cd /the/corresponding/mingw64/package/path && patch -p0 -u -i - --dry-run)
3) If the test run succeeded or if it had only one or two hunks different, I do the same without --dry-run and fix the possible rejected hunks.
4) In case I see that the differences are meaningless, I do eventually in the mingw32 package directory: "for i in *mingw32*; do cat $i | sed 's#mingw32#mingw64#g' | sed 's#MINGW32#MINGW64#g' >/the/corresponding/mingw64/package/path/`echo $i | sed 's#mingw32#mingw64#g'`; done
5) After I build the package and fix eventual build problems.
This is a reason why you will not find a patch called *mingw32*.patch it the packages, apart the mingw32-libqt4 package, where the patch actually is generated during upgrade from one to another version from the qt-<version>-mingw32.sh or qt-<version>-mingw64.sh scripts using wine and other tools and where the scripts are right to pass through my sed filter anyway :)
Thanks for the explanation.
A possible (but quite intrusive) solution could be to rename all the packages to just a mingw- prefix (without numbers) and do the same for the rpm macros. That way all the packages in win64 could be branched of the win32 packages. For most packages this would just work and packages that need specific changes, those can be added to the mingw64 package.
No, a common mingw- prefix is not a good idea, I have on my machine both mingw32 and mingw64 development environments. Now, there is another idea to keep both the mingw32 and mingw64 files in the win32 repository and link them to the win64. I somehow kind of like something similar, but but there are two drawbacks. In the web-interfaces, if you fix a mingw64 spec file, it will be a new spec in the link and then if you are not careful, changing it again in the corresponding win32 package will not have effect. So again it is not flawless.
Hmm yes, I see. A lot of our different viewpoints seem to come from our different use cases. You want to be able to build and install the mingw packages on all SUSE versions. I just want the BuildService to provide ready-build Windows binaries. (Hence I only enabled the OpenSUSE 11.4 i586 repository for my brached packages, because any more would be a waste of build cycles.) So for me the distinction between SUSE versions is meaningless and I see the two projects (win32, win64) as two different target platforms, which of course usually have the same (src) package name. So please, keep telling my why my proposals don't work, because there is a lot I haven't thought about. Well, let's set aside (or postpone) the merging of packages idea. How about just renaming the macros to drop the 32/64: _mingw_bindir for example. Then the mingw32-foo.spec and mingw64-foo.spec files would be exactly identical. For packages with intentional differences (like disabling java for win64) some %if macro could be used, just like when special casing for different distros. Then the only package that has a different specfile between win32 and win64 would be filesystem (and perhaps that pesky libqt). Without the need of sed, the automatic conversion of packages is even more fool proof (and I like that the differences are made explicit and not the result of a 10-minute sed/diff script), and that would be a nice starting point for evaluating whether further merging of packages is possible/desired.
Also, a commit to one will trigger the rebuild of both which might eventually be not a convenient stuff since we have more then 200 packages in each repository.
But practically always you don't commit to to one and leave the other untouched, but change both anyway.
I somehow still think that having two packages that are synchronized by human is for the time being better, but some simple solution that will not mean to uproot all and replant would be good to examine
F.
Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org