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