Add transmission-qt to the transmission package?

Add transmission-qt to the transmission package?

[Bodertz]

The transmission package (the transmission:gui output specifically) has
transmission-gtk, but I personally prefer transmission-qt.  By including
qtbase, qttools, and qtsvg, transmission-qt will also be built.

I've made a simple package that inherits from transmission to do this:

    (define-public tranmission-qt
      (package
       (inherit transmission)
       (name "transmission-qt")
       (inputs (modify-inputs (package-inputs transmission)
    			  (append qtbase qttools qtsvg)))))

This works, except that transmission-qt.desktop is moved to the gui
output due to the inherited 'move-gui phase.  I could figure out how to
remove that phase to fix that, of course.

But I'd prefer if transmission-qt were an option for the transmission
package directly, either under a new :qt output, or to have both
transmission-gtk and transmission-qt under the :gui output.  Or just a
separate package, transmission-qt.

Any thoughts on that?

Re: Add transmission-qt to the transmission package?

[Ian Eure]

Hi Bodertz,

On Sat, Dec 21, 2024, at 5:39 PM, Bodertz wrote:
> The transmission package (the transmission:gui output specifically) has
> transmission-gtk, but I personally prefer transmission-qt.  By including
> qtbase, qttools, and qtsvg, transmission-qt will also be built.
>
> I've made a simple package that inherits from transmission to do this:
>
>     (define-public tranmission-qt
>       (package
>        (inherit transmission)
>        (name "transmission-qt")
>        (inputs (modify-inputs (package-inputs transmission)
>     			  (append qtbase qttools qtsvg)))))
>
> This works, except that transmission-qt.desktop is moved to the gui
> output due to the inherited 'move-gui phase.  I could figure out how to
> remove that phase to fix that, of course.
>

Interesting, does this mean the existing "gui" output of transmission installs transmission-qt.desktop even though it doesn't include transmission-qt?  If so, that seems like a bug to me.

> But I'd prefer if transmission-qt were an option for the transmission
> package directly, either under a new :qt output, or to have both
> transmission-gtk and transmission-qt under the :gui output.  Or just a
> separate package, transmission-qt.
>

I *personally* lean towards separate packages, because I think packages are easier to find than outputs; and because it reduces the build footprint, due to needing fewer inputs.  Right now, if you build transmission, it needs the gtk libraries, even if you don't build the gui output.  So I think the best thing here is three packages: transmission (daemon only), transmission-gtk, and transmission-qt -- where the latter two are derived from the former.

However, this will break existing users' setups, since AFAIK there's no way to replace a specific output of a package with a different package.  So to avoid breakage, I think it'd be best to add a gui-qt output to the existing package -- assuming you're looking to contribute a patch to Guix for this.  If this is for a personal channel or something, you can do whatever makes sense for you.

  -- Ian

Re: Add transmission-qt to the transmission package?

[Bodertz]

> Interesting, does this mean the existing "gui" output of transmission
> installs transmission-qt.desktop even though it doesn't include
> transmission-qt?  If so, that seems like a bug to me.
>

No, no, the default transmission package doesn't create a
transmission-qt.desktop file.  I was just referring to my own package,
which creates builds and creates the desktop file for both
transmission-qt and transmission-gtk (since it has the required
dependencies for both), and then moves the transmission-gtk binary and
the desktop files into the the :gui output due to the inherited
'move-gui phase.

It moves the transmission-qt.desktop file as well because part of the
'move-gui phase is this:

    (for-each
     (lambda (dir)
       (rename-file (string-append #$output "/share/" dir)
                    (string-append #$output:gui "/share/" dir)))
     '("applications" "icons" "metainfo"))

> I *personally* lean towards separate packages, because I think
> packages are easier to find than outputs; and because it reduces the
> build footprint, due to needing fewer inputs.  Right now, if you build
> transmission, it needs the gtk libraries, even if you don't build the
> gui output.  So I think the best thing here is three packages:
> transmission (daemon only), transmission-gtk, and transmission-qt --
> where the latter two are derived from the former.

Yeah, I would prefer that as well.  And adding Qt as an additional
dependency makes that situation worse.