Ugh, I saw that on fedora recently. Why do distros do that? I guess those same distros also patch KStandardDirs to look for files there ? Or set KDEHOME or something so it will look there?
At any rate, with 2 done and posted to reviewboard. If I set KDEHOME to /usr/local (my kf5 prefix here) qt4 based khangman works fine here using the files installed by kdeedu-data into /usr/local/share/apps/kvtml/en . At any rate I'll do all I can to get khangman's frameworks port ready by the wed freeze so that won't be an issue anymore either. thanks, Jeremy On Sun, Oct 26, 2014 at 4:04 PM, šumski <[email protected]> wrote: > On Sunday 26 of October 2014 22:53:57 Jeremy Whiting wrote: >> Sumski, >> >> Yes, you're correct, that is an issue. We are considering a couple of >> fixes for that as outlined below. >> >> 1. Merge khangman's frameworks branch to master, so it will be qt5/kf5 >> based for the upcoming release, This way khangman and kanagram (the >> two applications that expect these files in kdeedu-data) will be able >> to find them fine. >> 2. Make kdeedu-data install files into share/apps and modify >> libkeduvocdocument to also look for the files there also. This way >> whether 1 happens or not both applications will be able to find the >> files just fine. >> >> I'll make 2 happen now, then look at what's needed in khangman itself >> to possibly do 1 above also by release, we'll see. > Err, sorry, i think this will also cause problems, as some distros customize > apps dir to e.g. share/kde4/apps... > > > Cheers, > Hrvoje >> thanks, >> Jeremy >> >> On Thu, Oct 23, 2014 at 12:08 PM, šumski <[email protected]> wrote: >> > On Thursday 23 of October 2014 16:33:48 Jeremy Whiting wrote: >> >> ---------- Forwarded message ---------- >> >> From: Jeremy Whiting <[email protected]> >> >> Date: Thu, Oct 23, 2014 at 8:31 AM >> >> Subject: kdeedu-data >> >> To: kde-packager <[email protected]>, KDE Edu <[email protected]> >> >> >> >> >> >> Hey packagers, >> >> >> >> A quick heads up about kdeedu-data strangeness. >> >> >> >> The upcoming KDE Applications 14.12 release will have some >> >> applications based on kdelibs4 and others based on kf5. Because some >> >> applications that use libkdeedu/libkeduvocdocument are going to be >> >> still based on kdelibs4 while others have already been ported to qt5 >> >> and kf5 there will be both libkdeedu and libkeduvocdocument tarballs >> >> released. Because both used to contain a handful of kvtml files, we >> >> moved them out into kdeedu-data which both libkdeedu and >> >> libkeduvocdocument should depend on (or at least khangman(kdelibs4) >> >> and kanagram(libkeduvocdocument) should depend on in order to run. >> >> >> >> Now kdeedu-data uses ecm instructions to build like other kf5 based >> >> applications. Is that going to be a problem to make both khangman and >> >> kanagram run time depend on these packages, while kdeedu-data at build >> >> time requires ecm to build? >> >> >> >> I'm open to other solutions, but this is the best we could come up >> >> with at this time. >> > >> > But will remaining kde4 apps know to find ${DATA_INSTALL_DIR} spoken with >> > e-c-m language? IOW, by default, kde4's ${DATA_INSTALL_DIR} = >> > "share/apps", with e- c-m it's "share"... >> > >> > >> > Cheers, >> > Hrvoje >> > >> >> thanks, >> >> Jeremy >> >> _______________________________________________ >> >> release-team mailing list >> >> [email protected] >> >> https://mail.kde.org/mailman/listinfo/release-team >> > >> > _______________________________________________ >> > release-team mailing list >> > [email protected] >> > https://mail.kde.org/mailman/listinfo/release-team >> >> _______________________________________________ >> release-team mailing list >> [email protected] >> https://mail.kde.org/mailman/listinfo/release-team > > _______________________________________________ > release-team mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/release-team > _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
