Hello, On 20/04/11 10:08, Maarten Bosmans wrote:
Some source packages have different names than the produced noarch packages (e.g. mingw32-cairo vs. mingw32-libcairo2). This is not a problem per se, but I thought it would be good to at least have the -debug package always have the same name as the package that provides the corresponding DLLs. So I propose the following name changes: (along with some -tools changes) mingw32-bzip2-debug mingw32-libbz2-debug mingw32-jasper-debug mingw32-libjasper-debug mingw32-jpeg-debug mingw32-libjpeg-debug mingw32-lcms-debug mingw32-liblcms-debug mingw32-lcms2-debug mingw32-liblcms2-debug mingw32-poppler-debug mingw32-libpoppler-debug mingw32-tiff-debug mingw32-libtiff-debug mingw32-tiff mingw32-libtiff-tools mingw32-rsvg-view mingw32-librsvg-tools mingw32-cairo-debug mingw32-libcairo2-debug mingw32-cairo-devel mingw32-libcairo2-devel
I would somehow wait with this, we have in some rpm specs several packages that produce dlls. I kept the debug packages based on the source rpm name, since they are one per source rpm. I don't think that changing this now will bring a huge advantage. But it is not a absolute no from my side, just need to think a bit more about it.
Furthermore, it would be good to move some bindir/*.exe to the -devel package, in order to make the main package as minimalistic as possible, with only the .dll file. This can be done for instance in libcroco, fontconfig and libxml2.
OK, here I think the good idea would be to see how the corresponding openSUSE native packages are split and split our packages accordingly. Moving into devel wholesale is not really the best approach though, because an exe there will pull dependency on dlls from other packages and you might find yourself to have more dependencies for build then before, since we don't need any exe file for building.
I'm not sure about querymodules.exe in pango. Should it go into -tools or can it go into -devel? Also, glib2 has gspawn-win32-helper.exe. Is that needed at runtime or can it also go into -tools? I myself never had the need for these programs.
The gspawn-win32-helper.exe is absolutely needed by glib on runtime :) The rule of the thumb would be to simply check what the openSUSE packages look like and split our packages accordingly. For some of the packages that have no official openSUSE counterpart, check the GNOME:Factory project that is the source of GNOME packages for openSUSE.
Then there is the problem of actually naming the debug package something different than the source package name with the -debug suffix. The definition of the macro in mingw32-filesystem suggests that it is possible to give it a package name as argument, so I have tried the following for mingw32-lcms: %_mingw32_debug_package liblcms-debug %_mingw32_debug_package -n liblcms-debug %_mingw32_debug_package(liblcms-debug) None of those work. How is this supposed to work? Currently no package uses the argument to rename the debug package, so there is no example. May be it isn't possible after all?
The macro _mingw32_debug_package is in macros.mingw32. It was never designed to do these things. One can change if one thinks it is a good idea, but I would leave the debug stuff just alone for the while. The priority would be to check whether one can do some more granularity in our packaging like having one rpm per dll (or for a group of dlls that always go together) for the while. No need though to use the openSUSE libwhatever_0_1 naming structure IMHO. Nevertheless, I would really love to have this rebuild finish before we do anything else. So that one can test the dependency tracking a bit. Cheers Fridrich -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org