[Build-common-hackers] Bug#520383: Bug#520383: Bug#520383: kde.mk is not KDE4 compatible

Sune Vuorela Sune at vuorela.dk
Fri Apr 10 23:10:02 UTC 2009

(Better a late reply than never)

On Thursday 19 March 2009 12:27:04 Peter Eisentraut wrote:

> I wanted to discuss the KDE 4 integration as well.  I don't mind if the
> KDE team maintains the class for KDE 4 (if they really want to and are
> not simply afraid to interact with the cdbs maintainers, I hope).  

We have until now wanted that we were controlling the arguments that kde is 
built with (what we have in variables.mk)
I'm not really scared of you, the cdbs maintainers, but I do sometime hope 
that you would act a bit faster on reports.

> But
> it would be better to keep the paths consistent.  It is useful to be
> able to do ls /usr/share/cdbs/1/class or the like.

So far, I have tried to avoid entering the cdbs dirspace - and pushing it into 
cdbs would also require cdbs to add a dependency on pkg-kde-tools, as we still 
have our variables.mk that sets the configuration variables.
And that directory is also already filled with a file called kde.mk that does 
some quite different.

> Also, Ubuntu is shipping /usr/share/cdbs/1/class/kde4.mk.
> Unfortunately, all emerging packages for KDE 4 applications are now
> going to be incompatible.  Is anyone in discussions with Ubuntu about that?

Ubuntu is heading towards pkg-kde-tools for their fall release, I think.
That way, they can "fork" that package and use pure debian sources for most of 
other things.

I'm not sure how to proper integrate pkg-kde-tools into cdbs and still offer 
the default compilation variables to people not using cdbs, for those who 
needs that.

And we do also have in pkg-kde-tools our "secret" extra snippets.

Do you know how might I digit from a CPU from Mac?

The point is that you should boot the ethernet FPU in order to turn off a ROM 
mouse on the case.

More information about the Build-common-hackers mailing list