[Buildroot] [PATCH v2 2/2] package/transmission: bump version to 4.0.3

[Yann E. MORIN]

Bernd, All,

On 2023-05-07 17:06 +0200, Bernd Kuhls spake thusly:
> Am Sun, 7 May 2023 12:52:18 +0200 schrieb Yann E. MORIN:
> >> Removed the option to disable uTP support, for details see upstream 
> issue:
> >> https://github.com/transmission/transmission/issues/4751
> > The option is still present, so why would we want to remove it?
> >     https://github.com/transmission/transmission/blob/main/CMakeLists.txt
> >     57  option(ENABLE_UTP "Build µTP support" ON)
> because building without utp support is broken:
> -- Configuring done
> CMake Error at libtransmission/CMakeLists.txt:273 (target_link_libraries):
>   Target "transmission" links to:
> 
>     libutp::libutp
> 
>   but the target was not found.  Possible reasons include:
> 
> libutp is required by https://github.com/transmission/transmission/blob/
> 0d3b321baca2cd02cc4b201826aed2b485e37c3f/libtransmission/
> CMakeLists.txt#L285
> 
> This was discussed upstream in the forementioned issue 4751
> https://github.com/transmission/transmission/issues/
> 4751#issuecomment-1464284585
> "... but as a practical matter, no distros are going to disable UTP 
> support. So I don't see an audience for this build option."

I did read the thread you mentioned, b efore I replied. But nowhere in
that thread is it mentionned that the option to build without was
actually removed, quite the opposite in fact.

First, @reardonia argued for keeping the option to build without libutp:

    https://github.com/transmission/transmission/issues/4751#issuecomment-1426548572

    Strongly prefer the WITH_UTP / ENABLE_UTP option. For a variety of
    safety issues, particularly with respect to private trackers, it's
    good to keep this disabled and reduce attack surface-area.

And eventually, @ckerr (a maintainer, I'd wager), seemed to change their
mind and accept @reardonia's request:

    https://github.com/transmission/transmission/issues/4751#issuecomment-1464284585

    @reardonia has done a lot of good patches and that sweat equity
    makes me look on this idea more favorably.

And finally, or completeness, here's the rest of the full comment you
partially quoted:

    but as a practical matter, no distros are going to disable UTP
    support. So I don't see an audience for this build option. And if
    that's the case, IDK if it makes sense to have it in transmission
    /transmission.

I.e. there is no explicit endorsement in that thread, that the option
has to be removed or not, and whether it was removed or not.

And in that CMakeLists.txt, one can also see:

    tr_allow_compile_if(
        ...
        [=[[ENABLE_UTP]]=]
            tr-utp.cc
        ...

    target_compile_definitions(${TR_NAME}
        PRIVATE
            ...
            $<$<BOOL:${ENABLE_UTP}>:WITH_UTP>
            ...

And all that seem to indicate that UTP support is still optional...

And indeed, the cmake option is still there (as I pointed out), but the
build is broken (as you pointed out).

So, maybe the build issue is really a bug?

In any case, just state something like that in the commit log:

    Even if the code seem to indicate that building without libutp or
    disabling UTP is possible, this cause build failures, so jsut make
    UTP mandatory.

Otherwise, all this is confusing.

Regards,
Yann E. MORIN.

> Getting rid of the libutp dependency in libtransmission was rejected btw:
> https://github.com/transmission/transmission/pull/4882/
> 
> Regards, Bernd
> 
> _______________________________________________
> buildroot mailing list
> buildroot at buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'