Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Bernd Kuhls <bernd.kuhls@t-online.de>
Cc: buildroot@uclibc.org
Subject: Re: [Buildroot] [PATCH v2 2/2] package/transmission: bump version to 4.0.3
Date: Sun, 7 May 2023 17:51:03 +0200	[thread overview]
Message-ID: <20230507155103.GY252090@scaer> (raw)
In-Reply-To: <pan$8f26f$e0484769$516297af$9e67e51c@ID-313208.user.individual.net>

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@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.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2023-05-07 15:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-06 16:05 [Buildroot] [PATCH v2 1/2] package/libutp: bump version Bernd Kuhls
2023-05-06 16:05 ` [Buildroot] [PATCH v2 2/2] package/transmission: bump version to 4.0.3 Bernd Kuhls
2023-05-07 10:52   ` Yann E. MORIN
     [not found]   ` <20230507105218.GH252090__6425.69195931486$1683456775$gmane$org@scaer>
2023-05-07 15:06     ` Bernd Kuhls
2023-05-07 15:51       ` Yann E. MORIN [this message]
2023-05-07 16:23   ` Yann E. MORIN
2023-05-07 16:18 ` [Buildroot] [PATCH v2 1/2] package/libutp: bump version Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230507155103.GY252090@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=bernd.kuhls@t-online.de \
    --cc=buildroot@uclibc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox