On Sunday 26 of October 2014 23:18:47 Jeremy Whiting wrote: > 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? Nope, it is enough to pass wanted DATA_INSTALL_DIR, then the value is used as define in kstandarddirs...
> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
