Packaging issues
Closed this issue · 5 comments
GoogleCodeExporter commented
As a frum packager of FOSS, I am quite pleased to see this project under
way. Yishar Koach!
A few questions about the packaging:
1) What advantage is there to using KHTML over QtWebKit on *NIX systems?
KHTML is a pretty heavy dependency for a program that isn't really KDE-
integrated, particularly where QtWebKit is anyways available.
2) Installing targets should be done by defining target.path then INSTALL
+= target. This is more portable, particularly on platforms which use an
.exe suffix for executables (e.g. Cygwin).
3) Installing data under /usr/share/ but the binary under /usr/local/bin
doesn't really conform to the FHS; everything should be under one prefix.
Since /usr/share/Orayta is hardcoded into the sources (which in itself is a
separate issue), then IMHO you should use /usr/bin instead.
A patch for 2) and 3) is attached.
Original issue reported on code.google.com by yselkow...@gmail.com on 6 Jun 2010 at 9:07
Attachments:
GoogleCodeExporter commented
Hi,
1) The unique engine was initially QtWebkit, but KHTML rendering is much
faster, so
it was added by default. (Windows program use QtWebkit)
yoch
Original comment by yoch.me...@gmail.com on 6 Jun 2010 at 12:08
GoogleCodeExporter commented
http://groups.google.com/group/toratemetqt/browse_thread/thread/b68f4af59ccd58b0
#
Original comment by yoch.me...@gmail.com on 6 Jun 2010 at 12:12
GoogleCodeExporter commented
why use KHTML or QtWebit? KHTML is basically useless and outdated and is
specifically kde. Just use Webkit so it can be installed in non-kde
environments without kde dependencies.
Original comment by ZNeil...@gmail.com on 12 Jul 2010 at 6:21
GoogleCodeExporter commented
Please include a tarball that non-ubuntu/debian or gentoo users can install
Original comment by ZNeil...@gmail.com on 12 Jul 2010 at 6:51
GoogleCodeExporter commented
I'm closing this.
KHTML is no longer used, and the source code can always be obainted from
http://code.google.com/p/orayta/source/checkout .
The packaging may still be non FHS, but it makes no sense to put the sources in
/bin, and anyway all programs Iv'e met do the same as us. So that gets a
'won't-fix'.
Original comment by moshe.wa...@gmail.com on 15 Sep 2011 at 6:51
- Changed state: Fixed