Hi, telegram-purple port has pidgin set as a dependency. Is this really necessary or is dependency toward libpurple enough? telegram-purple could be used from bitlbee or some other program which supports libpurple and not only pidgin. BR, Marko
Looks like majority of piding plugins has pidgin as run/build depends; though you could remove it on your end in ports
(In reply to Nathan from comment #1) Yes, I removed the dependency locally, and telegram-purple works ok together with bitlbee without pidgin. BR/Marko
Created attachment 206403 [details] Remove pidgin dependency Hi, I think also that pidgin dependency is unnecessary. I propose to remove both BUILD_DEPENDS and RUN_DEPENDS variables in the patch submitted. Regards.
A commit references this bug: Author: mandree Date: Sat Sep 7 20:28:42 UTC 2019 New revision: 511419 URL: https://svnweb.freebsd.org/changeset/ports/511419 Log: net-im/telegram-purple: remove net-im/pidgin dependency. It suffices for telegram-purple to depend on libpurple. PR: 227305 Submitted by: Marko Turk Approved by: jjuanino@gmail.com (maintainer) Changes: head/net-im/telegram-purple/Makefile
returning to pool, I don't intend to MFH. Someone else feel free, else we'll get this in 2019Q4 in 3½ weeks anyways. It's not under blanket approval because it /removes/ dependencies.
(In reply to Matthias Andree from comment #5) Fixes for any dependencies (missing, spurious, or otherwise) are covered by both the Approved by: blanket (not requiring maintainer approval) and MFH approval ^Triage: Since this has already been closed, assign to committer that resolved.
reopening, ongoing MFH discussion - I advise against it because I would not want a "pkg autoremove" to uninstall pidgin on quarterly after the change. I don't see dependency *removals* (that don't break the package) listed as a blanket approval here: <https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#ports-qa-blanket>
(In reply to Matthias Andree from comment #7) I interpreted comment 0, comment 2 and comment 3 to mean the dependency was spurious (unnecessary). If in fact, pidgin 'is' used when it is depended on in the port, which doesn't sound like the case, otherwise removing it would cause issues for head (latest) package users too, then I would say that pidgin ought to have been, and should be an optional dependency, with appropriate enable/disable configure/build args as appropriate, rather than being removed altogether.
(In reply to Kubilay Kocak from comment #8) tldr: 1) If it wasn't a necessary dependency (optional or required), it was spurious, and can be MFH'd without explicit approval 2) If it is a dependency (optional), it should be listed as such in the port, ie: re-added under an OPTION, and all commits merged back to quarterly, again under blanket approval for 'fix dependencies'.
That's just my take, if you see it another way, feel free to close
Kubilay, please cite article/book, chapter and verse that issues blanket approval to *remove* spurious _DEPENDS without explicit ports-secteam@ approval. I showed you two places I found, at least the article should be authoritative, but does NOT permit a blanket merge of such a change. My take - and I am not speaking on behalf of or after consulting with ports-secteam - is that the quarterly ports branch is supposed to be very stable, so we need to weigh the impact of a non-merge (we have an excess dependency on pidgin) versus the impact of a merge (which might remove pidgin in certain situations on, for instance, pkg autoremove, which would be damaging). I'd say merging isn't worth it, the change will flow back as 2019Q4 will be branched in three weeks' time. My bottom line is I am not going to request the MFH.