Opened 9 years ago
Closed 9 years ago
#47839 closed enhancement (fixed)
port:gwenview update/enhancement
Reported by: | RJVB (René Bertin) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | haspatch | Cc: | NicosPavlov, mkae (Marko Käning) |
Port: | gwenview |
Description
This patch brings port:gwenview (slightly) more uptodate, and corrects an issue with the +kipi variant (which has no right of existence and probably never built anyway). A missing dependency on port:libkipi is added.
Attachments (1)
Change History (9)
Changed 9 years ago by RJVB (René Bertin)
Attachment: | gwenview.dif added |
---|
comment:1 Changed 9 years ago by RJVB (René Bertin)
comment:3 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to rjvbertin@…:
This patch brings port:gwenview (slightly) more uptodate
I don't see any differences between gwenview 4.14.3 and commit 0486886b4a4fed0e756f6dca0ee3fd2ebbbe5dd5.
comment:4 Changed 9 years ago by NicosPavlov
What is the point of using Git as the commit 04868 corresponds to the release 4.14.3? Should another commit be used? And if yes, are there significant improvements in the code? In principle, we should avoid to pass to many KDE ports to git fetches, as this implies far longer build times for users, unless of course there is a significant gain in doing so.
comment:5 follow-up: 6 Changed 9 years ago by RJVB (René Bertin)
Hmm, you may be right that there's no point in using the git/head version; I did see there was little change. If any apparently. I had updated the package on KUbuntu where the "stock" version was older, that must have gotten me confused.
That said, I'm not sure why the build times would be far longer; using a git checkout doesn't prevent binary images from being built, does it?
Git checkouts can be made faster (a lot, for large and active repos) by using --depth=1 --no-single-branch
, which basically makes it impossible only to commit to the repository.
In general, we have little choice if we want to keep KDE4 ports up to date: bug fixes will often be made as git commits only.
@Nicos: what about DGWENVIEW_SEMANTICINFO_BACKEND=None?
comment:6 Changed 9 years ago by NicosPavlov
@Nicos: what about DGWENVIEW_SEMANTICINFO_BACKEND=None?
The fact of enabling the use of baloo can make sense, but I would not use it as default. As baloo requires additional setup by the user, such as activating the daemon, I suspect that most users would end up with additional ports installed which do not do anything, as they would not have been setup manually as required. I would suggest a variant +baloo, as it is being used already in other ports.
comment:7 Changed 9 years ago by mkae (Marko Käning)
Yes, please, a variant is fine, but do not enable it by default. One semantic search engine on a machine is enough! ;-)
comment:8 Changed 9 years ago by NicosPavlov
Resolution: | → fixed |
---|---|
Status: | new → closed |
Committed in r141936, apart from the git fetch.
Question to the maintainer:
Why not include a "semantic info backend" (i.e. configure with
-DGWENVIEW_SEMANTICINFO_BACKEND=None
)? Does the default baloo backend not work?