After the update to 4.0 transmission can no longer be installed modulary, by mixing the parts one wants, as for example -daemon and -utils conflict on /usr/local/etc/rc.d/transmission. If I see that right that could be solved by removing the options that overlap with another flavour: UTILS DAEMON and CLI.
(In reply to Benjamin Takacs from comment #0) This is correct. The idea was to move towards an install that would provide a reasonably complete install with -cli, -daemon, -gtk, and -qt. For this reason, daemon includes utils and web, while cli includes utils. A more customized approach is possible by building a flavor with different options. If this is rocking the boat too much, the port could be revised. It would be helpful to get a better sense of what the community prefers prior to doing so.
In my opinion (which you do not need to follow), it should work such that each flavour is a module and installing additional flavours makes additional modules available. So if you need the cli and the utils, you install these two flavours and then that's what you get. A metaport can be provided to gather modules that are commonly installed together (the metaport then just depends on these modules).
Created attachment 245028 [details] patch-transmission_1 *Fixes flavor conflicts in Bug 273841 *Patches to build with libfmt>=10.0. Bug 273887 *Adds log-location and log-level options. Bug 269392 *Fixes build errors arising from pkg-plist issues. Bug 273836
(In reply to Rafe from comment #3) Looks good, will proceed with a build test soon. What I don't get though is why the default flavour isn't just a metaport that depends on the other flavours. But I guess you evaluated this and found some reason why it wouldn't work like this.
> WEB_DESC= Install web client (requires daemon to run) This looks like use of OPT_IMPLIES may be in order. Or is the daemon bit perhaps supplied by a separate flavour? Your conflicts are set up so that ultimately, transmission-default conflicts with itself. I'm not sure if this is a problem. You could fix this by e.g. using .for f in ${FLAVORS:Ndefault} $f_CONFLICTS_INSTALL= transmission-default .endfor default_CONFLICTS_INSTALL= ${FLAVORS:Ndefault:@f@transmission-$f@} I'll have to test this thoroughly. It all looks a bit complex to me.
(In reply to Robert Clausecker from comment #5) Thanks for replying so quickly. There's a WEB_IMPLIES= DAEMON on line 155. I added the parenthetical to the description to avoid confusion for a user who deselects DAEMON and selects WEB. Absent an explanation, they might be confused when such a selection results in an install with DAEMON. I understand from § 5.16 of the porter's manual that it's acceptable for a port flavor to conflict with itself as it's specifically ignored. In testing, this worked properly. An installation of a flavor other than default caused the removal of default and vice-versa. A metaport would require separate builds for each component, right? If that's the preferred structure will change it. As-is, I have tested in poudriere on 13.2-amd64, 12.4-amd64, and 12.4-i386. Builds and cleanly and completes its test suite on all three.
Created attachment 245051 [details] patch-transmission_2 Updated WEB option DESC.
(In reply to Rafe from comment #6) Thank you for the clarification. The point of using a metaport is that it makes things easier for binary package users. For example, consider something else pulls in transmission as a dependency, but say it only needs the daemon bits, so it depends on net-p2p/transmission@daemon. But you want all the bits and so have net-p2p/transmission@default installed, and suddenly there is a conflict despite you having a dependency that works. A metaport makes it so that when you install net-p2p/transmission@default, it simply depends on net-p2p/transmission@daemon, meaning that the dependency can be satisfied. It also means users can easily install or deinstall components of transmission without having to go through a full install/deinstall. But at the end of the day, it's your decision and I'm fine with it either way.
(In reply to Robert Clausecker from comment #8) Thanks for your prompt attention. I think it's best to move forward as-is for now and perhaps revise as a metaport or rever to slave ports in the future. Poudriere does not build a flavor that depends on other flavors. The metaport would thus have to be separate and distinct in order for it to build. At that point, it might as well be structured as a metaport with slave ports instead of slave ports.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f40cba02c2f877b8e9e5e1a591c49ff118831c19 commit f40cba02c2f877b8e9e5e1a591c49ff118831c19 Author: Rafe <mondo.debater_0q@icloud.com> AuthorDate: 2023-09-19 19:37:51 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2023-09-22 04:56:47 +0000 net-p2p/transmission: Refine flavors, port fixes *Fixes flavor conflicts in Bug 273841 *Patches to build with libfmt>=10.0. Bug 273887 *Adds log-location and log-level options. Bug 269392 *Fixes build errors arising from pkg-plist issues. Bug 273836 See UPDATING for additional information on the usage of flavors. PR: 273841, 273887, 269392, 273836 Reported by: Benjamin Takacs <nimaje+fbz@bureaucracy.de> Reported by: diizzy, dereckson@gmail.com Reported by: Igor Pavlov <igor.arabesc.pavlov@gmail.com> UPDATING | 13 ++ net-p2p/transmission/Makefile | 87 +++++++----- .../files/extra-patch-CMakeLists.txt (new) | 23 +++ .../files/patch-gtk_Application.cc (new) | 11 ++ .../patch-libtransmission_file-posix.cc (new) | 11 ++ .../patch-libtransmission_variant-json.cc (new) | 11 ++ net-p2p/transmission/files/transmission.in | 12 +- net-p2p/transmission/pkg-plist.cli | 27 ---- net-p2p/transmission/pkg-plist.daemon | 12 +- net-p2p/transmission/pkg-plist.default (new) | 155 +++++++++++++++++++++ net-p2p/transmission/pkg-plist.full (gone) | 155 --------------------- net-p2p/transmission/pkg-plist.gtk | 30 +--- net-p2p/transmission/pkg-plist.qt | 27 ---- net-p2p/transmission/pkg-plist.utils | 10 -- 14 files changed, 290 insertions(+), 294 deletions(-)
Thank you for your contribution.
(In reply to Rafe from comment #9) > Poudriere does not build a flavor that depends on other flavors. Could you please clarify this part? Transmission is important piece of software for me, so perhaps I'll be able to help (though I can't promise that).
(In reply to Anton Saietskii from comment #12) Anton, there are no outstanding issues with the Transmission port that I am aware of at this time. Please update your tree to ensure that you are working from the most recent revision of the port (Rev. 1). Initially, the flavors did not behave as the prior slave ports did, causing user confusion. This has generally been corrected in rev. 1. From a user perspective, the only major difference at this point from the prior slave ports is that -web has been rolled into the -daemon flavor (where it is a default compile-time option). The issue under discussion arose due to the migration of the port from slave ports to flavors and how best to provide a "default" install that behaved similarly to the metaport and slaveports that existed under the old port. There are multiple ways that this could have been resolved, each with their own complications.
(In reply to Rafe from comment #13) Rafe, there's no issues with my tree. Let me cite you again: > revise as a metaport or rever to slave ports in the future > Poudriere does not build a flavor that depends on other flavors This, I'm asking you to explain what exactly meant by "Poudriere does not build ..." with an ultimate goal to try turning that future into now.
(In reply to Anton Saietskii from comment #14) If you have a port that depends on a different flavour of itself, Poudriere thinks it's a cyclic dependency and refuses to build the port. I believe that if this issue is fixed, it should be possible for ports to depend on other flavours of themselves.
(In reply to Robert Clausecker from comment #15) Got it, thanks. IMO easiest way to work around that would be creating metaport with RUN_DEPENDS on all transmission flavors, like done in graphics/gpu-firmware-kmod.
(In reply to Anton Saietskii from comment #16) That's what I recommended, too, but the maintainer would like to avoid the change in portname that would come with that.
I'm afraid this isn't fixed still: jason@jnb: [?:1] ~ $ poudriere options -sn net-p2p/transmission@daemon net-p2p/transmission@utils [00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf ===> The following configuration options are available for transmission-daemon-4.0.4_1: DOCS=off: Build and/or install documentation NLS=off: Native Language Support TESTS=off: Build & run unit tests WEB=off: Install web client (imples daemon) ===> Use 'make config' to modify these settings ===> The following configuration options are available for transmission-utils-4.0.4_1: NLS=off: Native Language Support TESTS=off: Build & run unit tests ===> Use 'make config' to modify these settings jason@jnb: [?:0] ~ $ sudo pkg install -n transmission-utils Updating poudriere repository catalogue... Fetching meta.conf: 100% 163 B 0.2kB/s 00:01 Fetching packagesite.pkg: 100% 149 KiB 152.4kB/s 00:01 Processing entries: 100% poudriere repository update completed. 602 packages processed. All repositories are up to date. Checking integrity... done (1 conflicting) - transmission-utils-4.0.4_1 conflicts with transmission-daemon-4.0.4_1 on /usr/local/etc/rc.d/transmission Checking integrity... done (0 conflicting) The following 2 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: transmission-daemon: 4.0.4_1 New packages to be INSTALLED: transmission-utils: 4.0.4_1 Number of packages to be removed: 1 Number of packages to be installed: 1 The process will require 5 MiB more space. jason@jnb: [?:1] ~ $
Created attachment 245217 [details] patch-transmission_3 Thanks, the attached patch should finally resolve this. FUZxxl, I would appreciate your thoughts about how to handle MOVED. Despite having PORTNAME=transmission, the flavors in net-p2p/transmission-components are not recognized as the proper port origin absent direction in MOVED. References to the prior changes in MOVED also had to be removed. Is there a better way to handle this? Happy to post to phabricator if that would make discussion easier.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ac3e39992e95659a5193a15d4cb873efb00fcb30 commit ac3e39992e95659a5193a15d4cb873efb00fcb30 Author: Rafe <mondo.debater_0q@icloud.com> AuthorDate: 2023-09-24 20:04:16 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2023-09-30 20:00:01 +0000 net-p2p/transmission: Reorganize as a metaport Port reorganized as a metaport. Each component can be installed separately or selected as an option via the metaport. Components were moved to net-p2p/transmission-components. See MOVED for additional information. Also fixes log-level typo in rc file and description errors PR: 273841, 274054 274065 Reported by: Anton Saietskii <vsasjason@gmail.com> Reported by: Matt <lazeraman@gmail.com> Reported by: Benjamin Takacs <nimaje+fbz@bureaucracy.de> Differential Revision: https://reviews.freebsd.org/D41975 MOVED | 12 +- UPDATING | 10 ++ net-p2p/Makefile | 1 + net-p2p/transmission-components/Makefile (new) | 189 +++++++++++++++++++++ .../distinfo | 0 .../files/patch-CMakeLists.txt} | 0 .../files/patch-gtk_Application.cc | 0 .../files/patch-gtk_DetailsDialog.cc | 0 .../files/patch-libtransmission_file-posix.cc | 0 .../files/patch-libtransmission_variant-json.cc | 0 .../files/patch-qt_transmission-qt.desktop (new) | 11 ++ .../files/transmission.in | 0 .../transmission-components/pkg-descr.cli (new) | 1 + .../transmission-components/pkg-descr.daemon (new) | 9 + .../transmission-components/pkg-descr.docs (new) | 1 + .../transmission-components/pkg-descr.gtk (new) | 1 + net-p2p/transmission-components/pkg-descr.qt (new) | 1 + .../transmission-components/pkg-descr.utils (new) | 1 + .../pkg-plist.cli | 0 .../transmission-components/pkg-plist.daemon (new) | 9 + .../transmission-components/pkg-plist.docs (new) | 10 ++ .../pkg-plist.gtk | 0 .../pkg-plist.qt | 2 +- .../pkg-plist.utils | 0 net-p2p/transmission/Makefile | 186 ++------------------ net-p2p/transmission/pkg-plist.daemon (gone) | 19 --- net-p2p/transmission/pkg-plist.default (gone) | 155 ----------------- 27 files changed, 264 insertions(+), 354 deletions(-)
I hope the port now finally works for good.