future of mingw

[Farkas Levente]

On 06/03/2011 04:39 PM, Erik van Pienbroek wrote:
> 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).

it's not the repo it's the kmod packaging guideline:
http://elrepo.org/tiki/kmodspec-el6
http://elrepo.org/tiki/kmodtool-el6


> 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).

that's an issue. the same spec file or even the same src.rpm should have
to be rebuild everywhere. and mho it's just depend on a good filesystem
package.

> 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

if macros are not enough you can still use shell scripts like in kernel
modules.

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

next week i hope will some time...

> 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).

it's not true. elrepo's spec file are generated and can be build in mock.

> 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/...).

that's not really important.

> 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?

is it important? is it have any value? imho not. i someone really want
to know than read base pacakge's description (same as docs and manuals,
otherwise we can generate it from the summary (for all subpackage too).

> 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.

no it's not try (see the kmod pacakges also) you can't see any BRs, but
of course it's generate a few (eg. kernel-devel).

> 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).

it can be also generated by a shell script.

> 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.

that's just the basic idea, but imho can done in a clean way too.

-- 
  Levente                               "Si vis pacem para bellum!"