Bug 246272 - net-p2p/transmission-daemon upgrade to version 3 failure
Summary: net-p2p/transmission-daemon upgrade to version 3 failure
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexandre C. Guimarães
URL: https://reviews.freebsd.org/D24851
Depends on:
Reported: 2020-05-07 06:55 UTC by Alessandro Sagratini
Modified: 2020-05-20 04:08 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (rigoletto)


Note You need to log in before you can comment on or make changes to this bug.
Description Alessandro Sagratini 2020-05-07 06:55:35 UTC
I'm installing latest version of transmission, transmission-daemon and transmission-web, version 3.00, using portmaster using following command:
portmaster net-p2p/transmission net-p2p/transmission-daemon www/transmission-web

Unfortunately, when trying to install transmission-daemon-3.00, process fails with following error:
===>  Installing for transmission-daemon-3.00
===>  Checking if transmission-daemon is already installed
===>   Registering installation for transmission-daemon-3.00
Installing transmission-daemon-3.00...
pkg-static: transmission-daemon-3.00 conflicts with transmission-cli-3.00 (installs files into the same place).  Problematic file: /usr/local/bin/transmission-create
*** Error code 70

make[1]: stopped in /srv/nas/freebsd-ports/net-p2p/transmission-daemon
*** Error code 1

make: stopped in /srv/nas/freebsd-ports/net-p2p/transmission-daemon

===>>> Installation of transmission-daemon-3.00 (net-p2p/transmission-daemon) failed
===>>> Aborting update

Output of "pkg list transmission-cli":
[root@nas ~]# pkg list transmission-cli

portmasterfail.txt does not show much, though:
cat portmasterfail.txt
portmaster <flags> net-p2p/transmission-daemon

Please let me know if there's anything else you need from me.
Thank you
Comment 1 Alexandre C. Guimarães freebsd_committer 2020-05-07 10:21:48 UTC
Hello! o/

First of all transmission-cli is self-contained and can't be used as transmission-daemon client, just transmission-gtk does (unless the support was also added to transmission-qt too, IDK) otherwise third party tools like Tremc also does.

That said, both transmission-cli and transmission-daemon need ENABLE_UTILS (transmission-create, transmission-show etc.) to be fully functional, and then the files will conflict.

In 2.xx series there were some differences of how transmission was built and the conflict could be avoided, but not anymore.

PS. I will leave this open for a while.

Thank you.
Comment 2 Alessandro Sagratini 2020-05-07 12:34:31 UTC
Thanks Alexandre for the feedback! I perfectly understand the reason is due to changes on how version 3.x vs 2.y transmission is built; this leads me to the following question, then: is it possible to change transmission configuration to make sure only one of "CLI" or "Daemon" options is chosen when building from source? I know it should, but would it make sense given new port behaviour?

Let me know if there's anything else you need from me
Comment 3 Alexandre C. Guimarães freebsd_committer 2020-05-07 13:32:59 UTC
(In reply to Alessandro Sagratini from comment #2)

If you are asking about the ability to enable/disable the ENABLE_UTILS support, this is feasible, and I am already considering adding that OPTION since several people asked the same, but I may just have time during the weekend or the next.

If you are in a hurry you can modify this line on the transmission-cli Makefile, removing the transmission variant you *don't* want to have the utils tooling:

.  if ${SLAVEPORT:Nweb:Ncli:Ndaemon}
Comment 4 Alessandro Sagratini 2020-05-07 13:54:54 UTC
thanks for the prompt answer Alexandre, you are correct; I think we can:
 1. either add a flag to enable/disable ENABLE_UTILS support option for cli and daemon packages so only one of them will provide those tools
 2. alternatively. the other option I was thinking about is using "OPTIONS_SINGLE" in net-p2p/transmission Makefile to make sure only cli *or* daemon is chosen

Based on your feedback, I understand it's a better idea to go with first option?

Finally, I am not really in a rush, at the moment and I can wait a couple of weeks til new patch is out :)

Let me know if there's anything else you need from me, thank you
Comment 5 Alexandre C. Guimarães freebsd_committer 2020-05-07 14:09:04 UTC
(In reply to Alessandro Sagratini from comment #4)

I need to look at it carefully because this port is particularly annoying to make changes. :-/
Comment 6 Alessandro Sagratini 2020-05-07 16:43:52 UTC
sure, that is absolutely fine :) If my thoughts are not applicable, we can think about a different solution
Comment 7 Alexandre C. Guimarães freebsd_committer 2020-05-15 08:12:32 UTC
The transmission port isn't just 1 port but involves a meta port, a master port, slaves ports, and a flavored slave port... everything tied in a complicated setup where you touch something in here and this break something in there.

In regards to using OPTIONS_SINGLE, in short, can't be done[1]. It can't be used to tell like if this option is ON for this slave port then disable for that one.

[1] may eventually be feasible but with a over-complicated setup.
Comment 8 Alessandro Sagratini 2020-05-15 10:17:00 UTC
not a problem Alexandre, thanks for the feedback!

At this point, I'm good with adding my interest in adding ENABLE_UTILS option to the port, if feasible: I'm not sure we should leave this PR opened, but if there's another one for the same exact request, we can simply go ahead and close this
Comment 9 commit-hook freebsd_committer 2020-05-20 01:52:10 UTC
A commit references this bug:

Author: rigoletto
Date: Wed May 20 01:52:07 UTC 2020
New revision: 535962
URL: https://svnweb.freebsd.org/changeset/ports/535962

  net-p2p/transmission: Allow all variants to be installed concurrently

  - split utils in a separated port

  PR:		246272
  Differential Revision:	https://reviews.freebsd.org/D24851

Comment 10 Alexandre C. Guimarães freebsd_committer 2020-05-20 04:08:18 UTC
Fixed. Thanks! :-D