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!" _______________________________________________ mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/mingw
