On Friday 26 of June 2009, Dirk Müller wrote:
On Thursday 25 June 2009, Lubos Lunak wrote:
Still, I think the < shouldn't be there. Old KDE apps should work with newer KDE base libraries.
Feel free to remove it from Factory:Desktop. as I said, it is a workaround for a different problem, and so far it was a good-enough hack.
Ok, but I will keep to my testing repository until I get this all ready.
I wanted to have a separate package with just the macros, to make it simple, I didn't know the directories didn't matter. But right now I still don't know how to solve the problem of using the same macros in all build repositories. Something for opensuse-buildservice@ I guess.
by using the same package (sourcelink, _aggregate etc) or by setting a prj config. Alternative you can also add specific .spec files for each individual repository, depending on what you're actually trying to achieve.
I think I've already handled this, I was suggested on opensuse-buildservice@ to create my own build repositories. I currently have 4 simple packages in home:llunak:kde that build and (mostly :) ) work on openSUSE, Fedora and Mandriva (with the same simple .spec file) and additionally also on Kubuntu (which is a bit of a pain for me). I now need to sort out all remaining important differences in paths and package names, figure out how to do Kubuntu in a less insane way, write howtos and it's ready to go. To continue on the topic, I'd like to clean up our kde4 rpm macros a bit. The plan is of course that the .spec files are written in a way that they are openSUSE .spec files and other distros are handled by mapping, but it would be nice to first sort them out. First of all, we don't have enough filepath macros. Meaning %_kde_share_dir and so on. For example, we put appdata in /usr/share/kde4/apps, but Mandriva has it in /usr/share/apps, while still having /usr/share/kde4/services, and we don't have a macro for that. I would like to extend our set to have one macro per location, so that we would write just something like %_kde_service_dir/kded/whatever instead of manually specifying the rest of the path after %_kde_share_dir. Also, our own macros are inconsistent. Some macros start with _kde_, some with _kde4_. Standard macros are like %_libdir (not %_lib_dir), but ours are %_kde_share_dir. I would like to make them consistent (and keep the old names for backwards compatibility of course), so that it's easier to use for potential new packagers (which later could also consider helping with maintaining KDE for openSUSE and we don't want to scare those away, do we ;) ? ). So, I checked also Fedora and Mandriva, and I would like the list to be: %_kde4_prefix %{_prefix} %_kde4_bindir %{_bindir} %_kde4_libdir %{_libdir} %_kde4_modules %{_libdir}/kde4 %_kde4_libexecdir %{_libexecdir}/kde4 %_kde4_sysconfdir %{_sysconfdir} %_kde4_sharedir %{_prefix}/share/kde4 %_kde4_appsdir %{_kde4_sharedir}/apps %_kde4_configdir %{_kde4_sharedir}/config %_kde4_applicationsdir %{_kde4_prefix}/share/applications/kde4 %_kde4_servicesdir %{_kde4_sharedir}/services %_kde4_servicetypes %{_kde4_sharedir}/servicetypes %_kde4_iconsdir %{_kde4_prefix}/share/icons %_kde4_docdir %{_kde4_prefix}/share/doc %_kde4_sbindir %{_kde4_prefix}/sbin %_kde4_includedir %{_kde4_prefix}/include Not that I insist on any specific form, but having this in some way would make things simpler. Another inconsistency is %cmake_kde4. Both on Mandriva and Fedora they imply an out-of-source build, but we have to explicitly state '-d build'. Are there actually any packages where this matters? I would like to change %cmake_kde4 to work like on Fedora and Mandriva, and ignore any passed -d for backwards compatibility. I will fix any possible package that would need adjusting because of this. In relation to this, although not specific to cross-distro builds, I'd like to change %make_jobs to something like this: %make_jobs \ if test -d doc; then \ %(__make} %{_smp_mflags} -C doc \ fi \ %{__make} %{?jobs:-j %{jobs}} VERBOSE=1 \ %{nil} I.e. first build documentation and only then run really in paralel. Most of our packages are not suitable for paralel building, paralel build in doc/ causes many meinproc instances that quickly eat all memory and I often run into this issue when testing a package locally (OOM-murderer kicks in and you know how much I hate that bloody broken thing). Comments, objections? -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org