rev 4397 - kde-extras/kile/trunk/debian

[Fathi Boudra]

irc discussions:

14:52 < allee> fabo: yeah, the problem sucks.  we've been there several times 
already.
14:53 < allee> fabo: from a distro point of view the optimal solution is to 
update the xml files kdelibs-data.  We don't have to care about kompatibility 
with KDE 3.2
14:55 < fabo> allee: kile devs must update (sync) their files in the 2 repo 
(kile + kde)
14:55 < allee> a compromise from the easy of maintaince may be to use 
alternatives and prio related to version
14:55 < fabo> or we need to create a meta like with these file
14:56 < fabo> i prefer an upstream resolution if possible
14:57 < allee> fabo: me too.  So sync kile, kde branch(es) is the leasst thing 
they can do for use ;)
14:57 < allee> fabo: but upstream can't sole the problem completely for us 
because they can't know when/if a branch pull is done.
15:00 < fabo> allee: they say that kile ones are the most up-to-date, maybe a 
script can "automagically" update kde svn ? independent (?) from our branch 
pull
15:04 < allee> fabo: would it be too painful to add a  grep test to compare 
installed kdelibs-data *.xml version with the one in kile and that FBTFS if 
kile has a more recent one?  (need build-dep on
               kdelibs-data)
15:06 < allee> mhmm, or an optional test (like pkg specific lintian check) + 
alternative for the two files.
15:06 < fabo> allee: yes, this is a possile solution
15:07 < allee> fabo: this may we^you ;) get an reminder to update .xml files 
in kdelibs-data and when kile is installed the kile always(?) more recent 
verson is used
15:12 < fabo> allee: hmm maybe we can just add a test in the branch pull to 
keep these files up-to-date ?
15:13 < fabo> allee: to resume-> we keep these file in kdelibs-data and in the 
branch pull we extract the most up-to-date files
15:16 < allee> fabo: mhhm, I not sure about readability of branchpull scripts  
if we have to add more and more such checks over time.
15:18 < fabo> allee: just an extra check for this particular case, or an other 
script can do it without touching branch pull
15:18 < allee> fabo: so decitated test in kile (or other apps seem more 
appealing to me).  Assumed that the individual pkg maintainer know more about 
the pkg specific test
15:19 < fabo> allee: anyway we've got some possible solution
15:20 < fabo> allee: i'll post the discussion and wait for feedbacks from 
upstream and maybe others Thucydides ? MadCoder ? ... ?
15:20 < MadCoder> fabo: honnestly, I don't care much about the problem
15:20 < MadCoder> I don't use kate
15:20 < MadCoder> ;P
15:20 < MadCoder> I feel it's better to have the one most up to date
15:21 < MadCoder> but I also feel wrong not to ship one if kile is not here
15:21  * fabo kicks MadCoder
15:21 < fabo> so the goal is clear, just how we'll do it :)
15:21 < allee> fabo: but: when this test triggers on out of date data in 
kdelibs-data. It the maintainer (or a sciript), create a patch for 
kdelibs-data, check in upstream version ind kde_branch is uptodate ->
               otherwise remind/pester upstream to do it
15:23 < MadCoder> fabo: alternatives ?
15:24 < allee> MadCoder: only alternatives means that without kile your 
latex/bibtex highlightning in kate(part) may be out of date
15:26 < MadCoder> so ?
15:26 < MadCoder> that's a fair trade between features and amount of work to 
throw in
15:26 < MadCoder> else the good way is to do the sync manually into 
kdelibs-data for those who have commit rights
15:26 < MadCoder> but it needs work, and may hurt prides
15:27 < allee> :)
15:29 < allee> fabo: I'll try to scriptify the version comparison
15:29 < fabo> allee: ok