Mailinglist Archive: opensuse-kde (169 mails)

[Lubos Lunak <l.lunak@xxxxxxx>]

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@xxxxxxx , l.lunak@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kde+help@xxxxxxxxxxxx