#52318 closed defect (fixed)
libproxy KDE variant modifications
| Reported by: | RJVB (René Bertin) | Owned by: | dbevans (David B. Evans) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | haspatch | Cc: | mkae (Marko Käning) |
| Port: | libproxy |
Description
The current port:libproxy's +KDE variant doesn't actually have any effect. The KDE module is built even without it.
In itself that's fine because that module now has a pure runtime dependency on KDE, but that also means that the +KDE variant no longer needs to pull in hard KDE dependencies.
The attached patch is a proposition. Since it's entirely unclear what use the KDE module has I have decided not to make it depend on any KDE or Qt port because a priori it won't even be used if no KDE software asks for it. And I have yet to find evidence that this is the case. There are no repercussions on the reproducible build principle.
I did include one additional change: with KDE being based on Qt/Cocoa (= using native APIs) it seems reasonable to let libproxy use native APIs too.
Is there a reason why this isn't the default, BTW, why libproxy isn't always built against native APIs which allow it to actually detect the system proxy correctly?
Attachments (1)
Change History (5)
Changed 8 years ago by RJVB (René Bertin)
| Attachment: | libproxy.diff added |
|---|
comment:1 Changed 8 years ago by mf2k (Frank Schima)
| Cc: | devans@… removed |
|---|---|
| Owner: | changed from macports-tickets@… to devans@… |
comment:2 Changed 8 years ago by mkae (Marko Käning)
| Cc: | mk@… added |
|---|
comment:3 Changed 7 years ago by dbevans (David B. Evans)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
KDE variant/plugin configuration issues addressed in changeset ce7ea3c
Cc Me!