[rkward-devel] rules revised

[meik michalke]

hi,

am Samstag, 1. August 2009 (14:20) schrieb Thomas Friedrichsmeier:
> I did that in 0.5.0d-2, because the previous debhelper compatibility
> version (4) had become deprecated. However, setting this to 6 is still
> allowed, so I did that in SVN.

thanks, that helped, it compiles again :-)

using /etc/issue could be a little more complex than i first thought, though. 
because on my system with all updates it says "Ubuntu 8.04.3 LTS", not "Ubuntu 
8.04 LTS".

well, nothing awk couldn't handle. on the other hand, "lsb_release -s -i -r" 
still answers "Ubuntu 8.04" (distribution & release) -- to get "Ubuntu 8.04.3 
LTS" you'd have to call "lsb_release -s -d" (description). so i wonder if 
lsb_release wasn't the cleaner solution after all?
 - awking through /etc/issue would do it, but in a less readable way, and
   it's more some dirty hack i think (because the issue file doesn't seem
   a safe place to get reliable release information)
 - lsb_release is clean and safe, but adds another build dependency
i don't know, i'm ok with both ways.

> There is another issue, which may be harder to fix, though: I dropped the
> cmake and libphonon-dev build-depends (see http://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=531086). I believe they are probably still required
> on hardy, though, as kdelibs5-dev there fails to depend on them(?).

you're right, kdelibs5-dev doesn't depend on them yet in version 4.0.3.

> So to build the .deb on hardy, you'd have to install those manually. Do you
> see a solution for that?

actually, i don't see the real issue that needs to be fixed in the first place 
;-) perhaps i don't get it, but as far as i see it: julien would like to see 
those build-depends dropped because "this 2 packages are already provided by 
kdelibs5-dev". kdelibs5-dev doesn't provide these packages but depends on them 
(in later versions), i guess that's what he meant, but it's still an important 
difference, seen though the eyes of debian package management. i think it 
never hurts to have a dependency that is satified already (in most cases), but 
you can really get into trouble if you start to depend on some other package's 
dependecies. what if kdelibs5-dev moves the cmake dependecy to its build-deps 
with the next release? it might be unlikely, but why risk it at all?

so i don't see this as a hardy issue but more general. i'd prefer to keep 
*all* packages *we* depend on in *our* dependency list, even if in most (but 
not all) cases these dependencies are probably already resolved by some other 
package. that's how i would interpret debian's policy:
 o http://www.debian.org/doc/debian-policy/footnotes.html#f13

> BTW, is there a semi-official source for KDE 4.1 or 4.2 on hardy? Those
> packaging issues really aren't the only problems with KDE 4.0.x, so
> perhaps, instead of trying to work around them, we should recommend to
> upgrade the kde4 packages? What do you think?

i think if you're really still stuck to hardy now it's not that you don't want 
newer software, but need a stable release with long support. there might be 
cases where semi-official kde4 packages are an option, but in most of these 
cases a full upgrade to a whole new ubuntu release would probably be the even 
more obvious approach. if this sums it up correctly, the only meaningful way 
to support 8.04 is with its own old kde4 libs.

8.04 will officially be supported by canonical until april 2011. i don't think 
we need to care for workarounds that long, at least none of us gave this very 
long term support promise for buggy kde4 versions to anyone directly ;-) but 
in my view, as a compromise we should at least try to keep it up until the 
next lts release is due, that should be next april. rkward users could be 
prepared that kde 4.0 support will finally cease in april 2010.

the alternative decision would be to drop hardy support completely, if it 
hinders the develeopment.

btw, i plan to close the 8.10 repository after the release of 9.10. so i 
think, as a rule of thumb, it's worthwhile to have packages for a) the recent 
release, b) its predecessor (for those who haven't upgraded yet) and c) the 
recent long term support release.


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/20090802/2cca35f3/attachment.sig>