Re: HEADS UP: openssl engine-related FTBFS and Boost

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2 Jul 2024 at 13:17, Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On Tue, 2 Jul 2024 at 14:07, Dmitry Belyavskiy <dbelyavs@xxxxxxxxxx> wrote:
>>
>> Dear colleagues,
>>
>> On Tue, Jul 2, 2024 at 1:35 PM Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>> This recent commit [1] in rawhide moves the engine API to a openssl-devel-engine subpackage following [2] (BTW this change announced that it would be openssl-engine-devel instead, but that's not the point). I'm surprised that FESCo approved this change without any analysis of the impact and the packages that required adaptation and how. Also, change owners are now allowed to commit and just let things break?
>>>
>>> One major concern is that I see this in a package that does **not** use the engine API:
>>>
>>> /usr/include/boost/asio/ssl/detail/openssl_types.hpp:26:11: fatal error: openssl/engine.h: No such file or directory
>>>    26 | # include <openssl/engine.h>
>>>       |           ^~~~~~~~~~~~~~~~~~
>>> compilation terminated.
>>>
>>> What are we supposed to do here? Aren't we allowed to add new packages to Fedora that require Boost ASIO because we would need to add a deprecated package to BR, even if the package itself doesn't use that API?
>>
>>
>> In the long-term it would be better to provide a patch fixing build of the package. Probably adding -DOPENSSL_NO_ENGINE to build flags will work.
>
>
> This should be documented in the change proposal. Does this work for Boost?
>
>>
>> Engines are deprecated. You should not use engines and should migrate to providers.
>
>
> I don't use engines. Boost does. I use Boost.

Boost Asio supports using engines, and it supports not using engines.
Boost doesn't make that decision, it leaves you to decide.


>
>> The implemented solution is an attempt to find balance between removing engines at all (not possible as of now) and delaying the migration to providers.
>> I'd recommend consider it as a gentle reminder about future engine deprecation
>
>
> Sorry but breaking packages without notice or a proposed solution is not gentle at all.
>
> --
> Iñaki Úcar
> --
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

-- 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux