Richard W.M. Jones wrote: > In response to this thread: > http://lists.fedoraproject.org/pipermail/fedora-mingw/2008-October/000001... > > As the packages get added to Fedora CVS, I'm requesting EL-5 branch > and building them. Part of the reason is that oVirt _may_ wish to > build a Windows client on RHEL/EPEL, and they have requested this. > Another reason is that there seems to be interest from CentOS users. > > It'd be useful to have EPEL co-maintainers though to make this task > easier. i can do that if you like, but i rather modify fedora's spec file in order to be able to build both fedora nad epel pacakges too (in this not too much work will have as a co-maintainer).

On Sat, Nov 08, 2008 at 10:53:21PM +0100, Farkas Levente wrote: > Richard W.M. Jones wrote: >> In response to this thread: >> http://lists.fedoraproject.org/pipermail/fedora-mingw/2008-October/000001... >> >> As the packages get added to Fedora CVS, I'm requesting EL-5 branch >> and building them. Part of the reason is that oVirt _may_ wish to >> build a Windows client on RHEL/EPEL, and they have requested this. >> Another reason is that there seems to be interest from CentOS users. >> >> It'd be useful to have EPEL co-maintainers though to make this task >> easier. > i can do that if you like, but i rather modify fedora's spec file in > order to be able to build both fedora nad epel pacakges too (in this not > too much work will have as a co-maintainer). You're all set up with a Fedora (FAS) account right? If so I'll set you up as co-maintainer on new EPEL packages. With Fedora/EPEL CVS, just in case you're not familiar, each branch (ie. F-9/F-10/F-11/EL-5) has its own specfile, sources and patches, so everything is separate.

On Sat, Nov 08, 2008 at 10:19:09AM +0000, Richard W.M. Jones wrote: > In response to this thread: > http://lists.fedoraproject.org/pipermail/fedora-mingw/2008-October/000001... > > As the packages get added to Fedora CVS, I'm requesting EL-5 branch > and building them. Part of the reason is that oVirt _may_ wish to > build a Windows client on RHEL/EPEL, and they have requested this. > Another reason is that there seems to be interest from CentOS users. The big question for EPEL-5 branches though is what version of the packages to build for MinGW. For the Fedora release & rawhide branches our plan was to have each MingGW build track the version + patches of the corresponding native build. If we apply that logic to EPEL-5, then we shouldn't be copying the Fedora 9 mingw packages there - we should be -resyncing them to match the versions distributed in RHEL-5.

On Mon, Nov 10, 2008 at 11:16:40AM +0100, Farkas Levente wrote: > Daniel P. Berrange wrote: >> On Sat, Nov 08, 2008 at 10:19:09AM +0000, Richard W.M. Jones wrote: >>> In response to this thread: >>> http://lists.fedoraproject.org/pipermail/fedora-mingw/2008-October/000001... >>> >>> As the packages get added to Fedora CVS, I'm requesting EL-5 branch >>> and building them. Part of the reason is that oVirt _may_ wish to >>> build a Windows client on RHEL/EPEL, and they have requested this. >>> Another reason is that there seems to be interest from CentOS users. >> The big question for EPEL-5 branches though is what version of the >> packages to build for MinGW. For the Fedora release & rawhide branches >> our plan was to have each MingGW build track the version + patches >> of the corresponding native build. >> >> If we apply that logic to EPEL-5, then we shouldn't be copying the >> Fedora 9 mingw packages there - we should be -resyncing them to >> match the versions distributed in RHEL-5. > imho if we use the fedora's version and patches that's still better than > not having mingw for epel. what's more epel packages usually are the > same version as in fedora not as in rhel. ok i know it's a bit confusing > since there is no mingw in rhel, but there is gtk2 in rhel which is > older then mingw32-gtk2, but imho still better than nothing. and to keep > two parallel version for eg. mingw32-gtk2 (one for fedora and one for > epel) it'd be waste of time of those people who package it. Well it kind of depends on what you're wanting to use EPEL version of MingGW packages for. If you want them simply so that you can build and develop Win32 apps on a RHEL-5 based host machine, then keeping the same versions as Fedora makes sense because it minimizes overhead. If you want a RHEL-5/EPEL-5 based system for sake of long term support/stability of packages, then you'll want the MinGW packages to track RHEL-5 native versions so you take advantage of all the bugfixes/security patches etc being applied to RHEL-5 versions.

On Mon, Nov 10, 2008 at 11:55:30AM +0100, Farkas Levente wrote: > Daniel P. Berrange wrote: >> On Mon, Nov 10, 2008 at 11:16:40AM +0100, Farkas Levente wrote: >>> Daniel P. Berrange wrote: >>>> On Sat, Nov 08, 2008 at 10:19:09AM +0000, Richard W.M. Jones wrote: >> Well it kind of depends on what you're wanting to use EPEL version of >> MingGW packages for. If you want them simply so that you can build and >> develop Win32 apps on a RHEL-5 based host machine, then keeping the same >> versions as Fedora makes sense because it minimizes overhead. If you want >> a RHEL-5/EPEL-5 based system for sake of long term support/stability of >> packages, then you'll want the MinGW packages to track RHEL-5 native >> versions so you take advantage of all the bugfixes/security patches etc >> being applied to RHEL-5 versions. > yes you've got right. if there's someone who'd like to do the extra work > to maintain an enterprise version of these packages, than it'd be > better, but until we can't find such fedora's version still more than > nothing. The interesting thing is that if we did want the same versions available in both Fedora & EPEL, then in theory most of the RPMs should basically end up with identical built DLLs regardless of build host. Only the native compiled toolchain RPMs would truely be different. So if we want to address the usecase of letting people use RHEL/EPEL as a host for developing Win32 apps, then it might be sufficient to just provide the toolchain natively in EPEL (eg the mingw-filesystem, mingw-binutils, mingw-gcc) and then pull in the existing RPMs of all the GTK like bits from Fedora with a magic YUM repo definition that restricts to only the mingw packages, eg [mingw] name=Mingw baseurl=http://download.fedoraproject.org/pub/linux/fedora/releases/10/$a... enabled=1 exclude=* includepkgs=mingw-* Though that's not quite perfect, because the mingw-* will still pull in the mingw-filesystem & gcc, & binutl bits if they happened to be newer. The yum include/exclude stuff is annoyingly not quite expressive enough.