Design a system, that allows packaging of dependencies and Conan itself for Linux package maintainers

[crsib]

No description provided.

[crsib]

Est: 2D

[falkTX]

FYI Linux package maintainers do NOT want to use conan, but have everything be from system packages.

[crsib]

There are several dependencies that are not accessible from the Linux package management software. For these cases, there will be a way provided to do a fully offline build that will only require Python as a build dependency.

[falkTX]

There are several dependencies that are not accessible from the Linux package management software.

Several? which ones?

If there is interest on packaging audacity, those dependencies will be packaged system-wide too.
This is not really an issue.

[crsib]

Nyquist and portmixer for now at least.

If Linux package maintainers will decide to include them - then it will be possible for them not to use Conan at all. However, Audacity builds on other platforms as well.

PS. It is fascinating how much opposition about package management there is from the Linux user, which is heavily based on package management.

[falkTX]

There is opposition to do things outside of the official package management.
Often the only software that does this are commercial tools that due to licensing can't be packaged in most distros as-is, so they need to generate generic binaries.

Audacity has a big issue of patching upstream dependencies without (at least visible) collaboration that gets the modifications sent upstream and be put into releases.

To give an example, Ardour is a DAW with quite the long list of dependencies.
The page https://nightly.ardour.org/list.php#build_deps lists all of them. That list is bigger than Audacity.
Ardour manages to build and run with stock versions of all those libraries.
There is a page dedicated to "Libraries Requiring Modified Versions" at https://ardour.org/current_dependencies.html. With only gtk2 on macOS being an exception, everything else can pretty much be used as-is.

[crsib]

Audacity has a big issue of patching upstream dependencies without (at least visible) collaboration that gets the modifications sent upstream and be put into releases.

It is possible to build Audacity using system-only libraries. The problem is mostly with wxWidget 3.0 is the latest version for most of the distros. We won't be lowering this requirement.

There is a branch almost ready to be merged that has POC build for Fedora using rpmbuild in a network-less fakeroot: #1030

Ardour has dependencies, that are vendored in (i. .e simply copied into the source tree). One example is VST3 SDK. Even Lua is there and the list is surprisingly large.

This is what I really want to avoid, as managing such dependencies is difficult and error-prone. I really think that if there will be a verifiable offline way to build Audacity for package maintainers and without having vendored libraries it will be satisfactory for package maintainers.

[falkTX]

VST3 SDK is an odd case, the linux support is still very experimental so projects often need to ship with custom patches.
It also does not support installing / packaging for linux in the usual way, steinbeing simply doesnt seem to care.
See steinbergmedia/vst3sdk#65 steinbergmedia/vst3sdk#68 and steinbergmedia/vst3sdk#77
VST3 SDK is an example of how NOT to manage an opensource project.
There is simply no way to package it, so projects that depend on it have no choice but to include its files directly.
And afaik ardour does not use the full "SDK" but only the header files.

On Lua, last time I checked Ardour had custom patches for it in order to disable garbage collector or whatever is there that makes it incompatible with RT audio.

I really think that if there will be a verifiable offline way to build Audacity for package maintainers and without having vendored libraries it will be satisfactory for package maintainers.

This is mandatory actually, ubuntu builders (maybe debian too, not sure) purposefully disable online/network access.

[crsib]

This is mandatory actually

And this is precisely what would be done in this task.