future of mingw

Fri Jun 3 14:39:33 UTC 2011

Farkas Levente schreef op vr 03-06-2011 om 00:23 [+0200]:
> imho as in f16 there'll be a mingw32->mingw transition it's time to
> change everything which is not perfect (even if it's never perfect).
> afais mingw is now very similar to elrepo (or Driver Update Program
> http://dup.et.redhat.com/). why?
> - both provides a lots of similar packages,
> - both are a made for something already in the base os,
> - have generated subpackages eg: foo-kmod has generated kmod-foo(-PAE)
> subpackage(s),
> - the user written spec file is very short (relative to the generated ones),
> - both use some kind of (dozens of) macros and scripts to help create
> spec files.
> even if i not always agree with the current state of elrepo they are
> really getting better.

It's correct that we're preparing mingw-w64 support at the moment and
that we're also fixing various long-standing issues at the same time.

I don't really see the similarities with third party repos like elrepo
or dup. At the moment there is a special repo online which contains the
mingw-w64 packages, but this repo is only temporary. It is being used
for testing purposes until it's stable enough (which it should be by
now).

The only thing which is holding back the introduction of mingw-w64 to
Fedora is a legal approval from RH Legal. Once we have the approval, all
changes which were done in the testing repo will be merged back into
Fedora and the testing repo will disappear (as it will be obsolete by
then).

> generality:
> there're a lots of people who'd like to use it: fedora, rhel/centos,
> suse, mandrake not to mention the hidden people. would be useful for the
> "community" to create something which is (very easily) reusable. means
> only a rebuild needed (and may be the filesystem package can be
> different for the different disto/people).
> currently it's much more complicated. yes i know it's only for fedora,
> but if it's only required a little more work why not we do it in that
> way? see later my proposal.

I don't really see any blocking issues here. If other RPM based distros
wish to use our packages they're free to do so. Bootstrapping is also
quite easy, see
https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework#Phase_3:_Bootstrap_the_mingw-w64_toolchain for details about that (that document is a bit outdated as it still mentions the prefix 'cross-' instead of 'mingw-', but other than that the method is still the same).

The only blocking issue I can think of is the RPM 4.9 changes which were
applied to Fedora 16 recently by Kalev Lember. As RHEL6 doesn't have
this version of RPM the building of packages can fail. There has been
some discussion about this subject recently on this mailing list, see
http://lists.fedoraproject.org/pipermail/mingw/2011-May/003654.html for
more details. However, it is quite possible that Red Hat will backport
this RPM 4.9 feature in a future RHEL 6.x release (like was also done
with LZMA support during the RHEL 5 life cycle).

If you maintain mingw packages which are also in EPEL then you're free
to decide for yourself if you want to stick with the old method of
provides/requires extraction or use the RPM 4.9 method for this. We do
recommend to use the new method, but in the end it's up to the package
maintainer to decide.

> clarity:
> it's always tell "if it's shorter than it's better, since cleaner and
> more easily readable". does the current spec file the cleaner and
> shortest? imho not. see later my proposal.
> what's the current rules? do we need static and debuginfo packages for
> mingw or not? half of the packages has these subpackages half doesn't.
> it'd be useful to clear it also.
> anyway what's the debuginfo packages good for in case of mingw? or they
> are only for cygwin gdb on windows?

The debuginfo feature wasn't mentioned in the original MinGW packaging
guidelines as this feature was added at a later time and we didn't
update the packaging guidelines. That's why several packages use this
feature and others don't. In the new (mingw-w64 based) packaging
guidelines we've added a section which says that the debuginfo feature
must be used in all mingw packages.

The idea behind this feature is that the mingw packages only provide
stripped libraries. If debugging symbols are needed, then the developer
can install the -debuginfo package and use gdb to do their debugging
work. The .debug files (provided by the -debuginfo packages) can also be
used on Win32 in combination with gdb if they're placed in the same
folder as the .dll's.

The original MinGW packaging guidelines also state that static libraries
shouldn't be bundled in the packages (as is the case with native Fedora
packages). However, over the time there has been a demand to provide
static libraries and thus various packages started to providing them.
The new (mingw-w64 based) packaging guidelines have also been updated to
allow static subpackages (that is, if the maintainer wants to provide
them).

> simplicity:
> the current spec file the simplest and easily created ones?
> if i see any of my programmer doing copy'n'paste they already know i'll
> be very angry. let's see
> http://fedoraproject.org/wiki/Packaging:MinGW_Future
> does the current spec file has any copy'n'paste?
> imho much more then needed.
> do you really think that the current mingw32-/mingw64- subpackage
> definition is the simplest, easiest?
> do you really think that anything from %description to %prep has any
> value? if we drop docs, man pages, etc. cause we referring to the
> original (non mingw package) then these part has any value?
> imho almost nothing.

You're correct that there's quite a lot of duplication in the example
spec file in the new (mingw-w64 based) packaging guidelines. During the
development of the mingw-w64 based packages I've tried to reduce the
amount of duplication required to an absolute minimum. However, I
stumbled across several limitations in the use of RPM macros. In other
situations I've found out that the result made the spec files
unnecessary hard to read. Also see the discussion at
http://lists.fedoraproject.org/pipermail/mingw/2011-January/003285.html
and
http://lists.fedoraproject.org/pipermail/mingw/2011-February/003367.html

If you think you can reduce the amount the duplication and get it to
work I would be glad to hear about it!

> here the situation is exactly the same as in kmodtool (ie. elrepo case).
> their spec files are very similar so they create a template and a shell
> script which generate most of the common part of the spec file. i never
> agree with them to use kmodtool in stead of rpm macros for this (what's
> more copy to all packages:-() but the base idea can be steal from there.
> they drop su

Dynamically creating spec files won't work in Fedora as the build
infrastructure doesn't support this. This will also break compatibility
with other distro's for sure (which is a bad thing as you mentioned
earlier).

> so my proposal:
> - start from the end and create the ideal spec file template.
> - enhance filesystem with a few macros to support the ideal spec file.
> - make some decision (do we need static and debuginfo or not).
> - let's create some macros which generate the common part of all spec files.
> - propose the new guideline to FESCo.
> - rewrite all spec file.
> 
> the ideal spec file only contains which has any relevant info (let's
> drop everything else:-) from the
> -------------------------------------
> Name:           cross-example
> Version:        1.0.0
> Release:        1%{?dist}
> Summary:        Cross compiled example library
> License:        LGPLv2+
> URL:            http://fedoraproject.org
> Source0:        http://fedoraproject.org/example-%{version}.tar.bz2
> 
> // all of these defines are optional
> %global cross_build_requires gettext win-iconv zlib
> %global cross_build_win 1 // equal to the two next defs
> %global cross_build_win32 1
> %global cross_build_win64 1
> %global cross_build_darwinx 1
> %global cross_no_debug 1
> %global cross_no_static 1
> %{?cross_spec_begin}
> 
> %prep
> %setup -q -n %{cross_pkg_name}-%{version}
> 
> %build
> %{cross_configure "--enable-static" "--enable-shared" "--enable-foo"}
> %{cross_make %{?_smp_mflags}}
> 
> %install
> %{cross_make_install "DESTDIR=$RPM_BUILD_ROOT"}
> 
> %{cross_find_lang %{mingw_pkg_name}}
> 
> %{cross_files "" "%{cross_bindir}/libexample-0.dll \
> %{cross_includedir}/example/ \
> %{cross_libdir}/libexample.dll.a \
> %{cross_libdir}/libexample.la \
> %{cross_libdir}/pkgconfig/example.pc"}
> 
> // for tools subpackage
> %{cross_files "tools" "%{cross_libdir}/libexample.a"}
> 
> %{?cross_spec_end}
> 
> 
> %changelog
> -------------------------------------
> isn't it much simple and easier to read?
> is there any _useful_ info missing from it?
> can it be generated by macros? ok i don't really know that, but i assume
> it's possible. and if you also think we can choose this way i start to
> implement it (may be some others can help me:-)

While developing the mingw-w64 based packages I also used something
similar to this as starting point. However, as I mentioned earlier it
turned out that various things aren't possible with RPM..

There are various issues with this approach:

The name 'cross-' as prefix is frowned upon heavily by various people in
Fedora as each cross compiled target has it's own characteristics
(desktop/embedded/...).

I'm missing the %description here in this approach. If it's hidden
behind the %{?cross_spec_begin} macro, how can packagers influence the
value of the description mentioned there?

The %{?cross_spec_begin} won't give you the expected results. For
example, if some BuildRequires tags is generated using that macro then
it won't be visible if the mingw-filesystem package isn't installed
(which is always the case when using mock or the Fedora build
infrastructure as it isn't part of the base packages). So if you try to
build such a package using mock then it won't see any BuildRequires tags
and result in a build failure.

If you want to support Win32, Win64 and Darwinx then your filelist won't
work correctly. For example, Win32 and Win64 use .dll's for shared
libraries while Darwinx uses .dylib's for that (and places them in
libdir instead of bindir).

I personally find the filelist hard to read. Only if you look really
hard you can see that there's a %{cross_files} macro which spans all the
way until the last file. The use of \'s at the end of each line also
make this error prone.

Another thing that may be an interesting read for you is the ticket we
filed at the Fedora Packaging Committee to get the mingw-w64 based
guidelines approved: https://fedorahosted.org/fpc/ticket/71
The discussion in the mingw-filesystem review ticket may also be
interesting to you: https://bugzilla.redhat.com/show_bug.cgi?id=673784

Please don't let this all discourage you. If you (or anybody else) can
come up with methods to making the example spec file at
http://fedoraproject.org/wiki/Packaging:MinGW_Future more readable and
smaller I would be glad to hear about it so we can use it for future
mingw packages!

Kind regards,

Erik van Pienbroek