Mailinglist Archive: opensuse-mingw (33 mails)

[Maarten Bosmans <mkbosmans@xxxxxxxxx>]

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 <fridrich.strba@xxxxxxxxxx>:
> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-mingw+help@xxxxxxxxxxxx