[rkward-devel] rules revised

[meik michalke]

hi,

am Freitag, 7. August 2009 (22:43) schrieb Thomas Friedrichsmeier:
> Ok, my assumption was that the problem is in fact tied to kdelibs 4.0.x
> debian packages in general, not hardy.

at least not at this point. hardy was delivered with kde3, so kde4 is being 
installed in a slightly different path, which should be true for later kde4 
versions packed for hardy as well. so we need to check if we're compiling for 
hardy, add that path to $PATH (otherwise kde4-config won't be found) and apply 
the small patch that also just changes the path for the k-menu entry. i don't 
know where debian installs kdelibs 4.0.x.

on the other hand, i think your approach could still be useful for problems 
that are actually kde 4.0.x related. if it's not too big changes to work 
around kde 4.0 bugs, you could put them in a patch of their own (and leave the 
sources written for later versions of kdelibs). of course this would mean the 
patches are only applied when a debian package is build, a cmake build would 
fail, though. therefore it might be good as it is, to deal with library bugs 
in the code directly but with distribution specific issues in the packaging 
process?

> > what about this: we add lsb-release to the build-deps for the time being,
> > and drop it again in april 2010, together with hardy support? [that is,
> > if no one uses the tool to discover other distribution details until
> > then.]
>
> Well, let's put this in for now (please increase the version number to
> 0.5.1-2 on the .deb, when you do so).

i don't plan to re-package because of that, because only the package building 
itself is concerned. but it will help for the next packages to be build.

> We'll have to wait and see what happens with regard to inclusion in the
> official debian/ubuntu archives, though.

if they don't like the "one diff for all" idea we could strip the added ubuntu 
parts again and create an ubuntu diff. it would still help building it for 
different ubuntu incarnations, but miss the opportunity to maintain only one 
unified build mechanism.

> I need to convince a debian developer of the quality of the packaging each
> time. So that's why I'm trying this hard to find an aesthetically pleasing
> solution.

yes, sounds desireable :-) 


viele grüße :: m.eik

-- 
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20090809/a7ea9836/attachment.sig>