Fwd: kdeedu-data
Jeremy Whiting
jpwhiting at kde.org
Sun Oct 26 22:18:47 UTC 2014
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 <hrvoje.senjan at gmail.com> 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 <hrvoje.senjan at gmail.com> wrote:
>> > On Thursday 23 of October 2014 16:33:48 Jeremy Whiting wrote:
>> >> ---------- Forwarded message ----------
>> >> From: Jeremy Whiting <jpwhiting at kde.org>
>> >> Date: Thu, Oct 23, 2014 at 8:31 AM
>> >> Subject: kdeedu-data
>> >> To: kde-packager <kde-packager at kde.org>, KDE Edu <kde-edu at kde.org>
>> >>
>> >>
>> >> 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
>> >> release-team at kde.org
>> >> https://mail.kde.org/mailman/listinfo/release-team
>> >
>> > _______________________________________________
>> > release-team mailing list
>> > release-team at kde.org
>> > https://mail.kde.org/mailman/listinfo/release-team
>>
>> _______________________________________________
>> release-team mailing list
>> release-team at kde.org
>> https://mail.kde.org/mailman/listinfo/release-team
>
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
More information about the release-team
mailing list