Bug 227305

Summary: net-im/telegram-purple: possible unneeded dependency
Product: Ports & Packages Reporter: Marko Turk <mt>
Component: Individual Port(s)Assignee: Matthias Andree <mandree>
Status: Closed FIXED    
Severity: Affects Some People CC: jjuanino, mandree, ndowens04, w.schwarzenfeld
Priority: --- Flags: jjuanino: maintainer-feedback+
koobs: merge-quarterly-
Version: Latest   
Hardware: Any   
OS: Any   
Description Flags
Remove pidgin dependency jjuanino: maintainer-approval+

Description Marko Turk 2018-04-05 19:55:01 UTC

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.

Comment 1 Nathan 2018-09-03 02:41:51 UTC
Looks like majority of piding plugins has pidgin as run/build depends; though you could remove it on your end in ports
Comment 2 Marko Turk 2019-01-02 09:49:12 UTC
(In reply to Nathan from comment #1)

Yes, I removed the dependency locally, and telegram-purple works ok together with bitlbee without pidgin.

Comment 3 jjuanino 2019-08-09 18:29:50 UTC
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.
Comment 4 commit-hook freebsd_committer 2019-09-07 20:29:19 UTC
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

  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)

Comment 5 Matthias Andree freebsd_committer 2019-09-07 20:34:28 UTC
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.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-08 04:09:53 UTC
(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.
Comment 7 Matthias Andree freebsd_committer 2019-09-08 07:49:12 UTC
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:
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-08 09:59:32 UTC
(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.
Comment 9 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-08 10:01:37 UTC
(In reply to Kubilay Kocak from comment #8)


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'.
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-08 10:02:52 UTC
That's just my take, if you see it another way, feel free to close
Comment 11 Matthias Andree freebsd_committer 2019-09-08 11:21:02 UTC
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.