Subject: Re: Bug#1104092: libftdi1 reduce Build-Depends for architecture bootstrap

From: Aurelien Jarno <[email-masked]>
Date: Fri, 25 Apr 2025 21:35:06 +0200

Hi Helmut,

On 2025-04-24 08:26, Helmut Grohne wrote:
> Source: libftdi1
> Version: 1.5-10
> Tags: patch
> User: [email-masked]
> Usertags: rebootstrap
> 
> Hi Aurelien,
> 
> I learned that libftdi1 technically became part of the architecture
> cross bootstrap set and that results in severe constraints about what it
> can depend on. The root cause is the addition of libtss2-dev to gnupg's
> Build-Depends from from libftdi1 via boost it goes really bad. Some
> package will have to get a build profile.
> 
> As part of this, I've looked into libftdi1 and tried reducing its
> dependencies. I see three main opportunities.
>  * We can turn libboost-test-dev optional via <!nocheck>, but we retain
>    libboost-dev for libftdipp.

Agreed.

>  * We can make all that Python stuff optional via <!nopython> and that
>    works really well, because py3vers returns an empty sequence when
>    missing and that makes stuff mostly just work. The exception here is
>    override_dh_auto_install-arch, because the last installed version
>    "wins". To make things reproducible, the main build needs to be
>    installed last.

The reason why the python build is installed last is to have a correct 
.pc file which includes LIBFTDI_PYTHON_MODULE_PATH, and your patch 
breaks that for the standard builds.

It also means that the nopython profile produces a slightly different 
libftdi1-dev, and I am not sure it is something allowed.

>  * Making libftdipp (and thus boost) optional is difficult, because the
>    CMake files installed into libftdi1-dev contain information about
>    libftdipp1-dev and that goes missing if you -DFTDIPP:BOOL=OFF, so
>    it'd be unreproducible.

One way would be to stop using boost, as it seems to only be used for 
boost::shared_ptr, so there might be an alternative. But that kind of 
change has to be done at the upstream level.

> I'm attaching a patch for the first two items as those feel like fairly
> direct improvements with little downsides. Would you agree to merge
> them?

I am find merging the nocheck part, but as explained above, I think the 
nopython part needs improvements.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[email-masked]                     http://aurel32.net