Оффлайн установка зависимостей для ПО

Во-первых, пакет libvlc-dev есть в репозитории дистрибутива, ниже пример для Astra Linux 1.7:

$ apt search vlc-dev
Сортировка… Готово
Полнотекстовый поиск… Готово
libvlc-dev/stable 3.0.21-0astra2+b3 amd64
  development files for libvlc

$ lsb_release -a
No LSB modules are available.
Distributor ID: AstraLinux
Description:    Astra Linux 1.7 x86-64
Release:        1.7_x86-64
Codename:       1.7_x86-64

Во-вторых, ставить сторонние deb пакеты в сертифицированный дистрибутив нельзя. На то он и сертифицированный. Кроме того, установкой пакета от другого DEB дистрибутива вы можете сломать систему. На уровне зависимостей пакетов или на уровне проблем с мандатным доступом, если это SE дистрибутив и в нём включены уровни защиты Воронеж или Смоленск.

Сейчас мы подкладываем deb пакеты libvlc-dev и его зависимостей (libvlccore9, libvlc5) в наш инсталлятор (самописный)

Это неправильный подход. Правильным способом - будет установка сборочных зависимостей только из сертифицированного официального репозитория и далее сборка DEB пакетов с вашим ПО и установка его посредством DEB пакетов в систему. Без какого-то вашего непонятно инсталлятора, который ещё и библиотеки будет куда-то подкладывать в сертифицированный дистрибутив.

Вот список файлов в libvlc-dev в Astra SE 1.7.9:

dpkg-deb -c libvlc-dev_3.0.21-0astra2+b3_amd64.deb
drwxr-xr-x root/root         0 2025-10-21 22:36 ./
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/include/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/include/vlc/
-rw-r--r-- root/root     14048 2025-10-21 22:36 ./usr/include/vlc/deprecated.h
-rw-r--r-- root/root     19716 2025-10-21 22:36 ./usr/include/vlc/libvlc.h
-rw-r--r-- root/root      8010 2025-10-21 22:36 ./usr/include/vlc/libvlc_dialog.h
-rw-r--r-- root/root      7876 2025-10-21 22:36 ./usr/include/vlc/libvlc_events.h
-rw-r--r-- root/root     28514 2025-10-21 22:36 ./usr/include/vlc/libvlc_media.h
-rw-r--r-- root/root      6058 2025-10-21 22:36 ./usr/include/vlc/libvlc_media_discoverer.h
-rw-r--r-- root/root      2912 2025-10-21 22:36 ./usr/include/vlc/libvlc_media_library.h
-rw-r--r-- root/root      6349 2025-10-21 22:36 ./usr/include/vlc/libvlc_media_list.h
-rw-r--r-- root/root      7127 2025-10-21 22:36 ./usr/include/vlc/libvlc_media_list_player.h
-rw-r--r-- root/root     72972 2025-10-21 22:36 ./usr/include/vlc/libvlc_media_player.h
-rw-r--r-- root/root      7392 2025-10-21 22:36 ./usr/include/vlc/libvlc_renderer_discoverer.h
-rw-r--r-- root/root      2148 2025-10-21 22:36 ./usr/include/vlc/libvlc_version.h
-rw-r--r-- root/root     12426 2025-10-21 22:36 ./usr/include/vlc/libvlc_vlm.h
-rw-r--r-- root/root      1943 2025-10-21 22:36 ./usr/include/vlc/vlc.h
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/lib/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/lib/x86_64-linux-gnu/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/lib/x86_64-linux-gnu/pkgconfig/
-rw-r--r-- root/root       271 2025-10-21 22:36 ./usr/lib/x86_64-linux-gnu/pkgconfig/libvlc.pc
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/bug/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/bug/libvlc-dev/
-rw-r--r-- root/root       292 2022-11-23 21:49 ./usr/share/bug/libvlc-dev/control
-rw-r--r-- root/root      1156 2022-11-23 21:49 ./usr/share/bug/libvlc-dev/presubj
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/doc/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/doc/libvlc-dev/
-rw-r--r-- root/root       206 2025-10-21 22:36 ./usr/share/doc/libvlc-dev/changelog.Debian.amd64.gz
-rw-r--r-- root/root      3207 2025-10-21 22:36 ./usr/share/doc/libvlc-dev/changelog.Debian.gz
-rw-r--r-- root/root     70963 2024-06-05 18:57 ./usr/share/doc/libvlc-dev/changelog.gz
-rw-r--r-- root/root     59112 2022-12-06 01:04 ./usr/share/doc/libvlc-dev/copyright
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/doc/libvlc-dev/examples/
drwxr-xr-x root/root         0 2024-06-05 19:07 ./usr/share/doc/libvlc-dev/examples/QtPlayer/
-rw-r--r-- root/root       484 2017-11-24 18:29 ./usr/share/doc/libvlc-dev/examples/QtPlayer/LICENSE
-rw-r--r-- root/root       158 2022-02-15 20:24 ./usr/share/doc/libvlc-dev/examples/QtPlayer/QtVLC.pro
-rw-r--r-- root/root       580 2022-02-15 20:24 ./usr/share/doc/libvlc-dev/examples/QtPlayer/main.cpp
-rw-r--r-- root/root      7112 2024-06-05 18:56 ./usr/share/doc/libvlc-dev/examples/QtPlayer/player.cpp
-rw-r--r-- root/root      1175 2022-02-15 20:24 ./usr/share/doc/libvlc-dev/examples/QtPlayer/player.h
-rw-r--r-- root/root      4920 2024-06-05 18:56 ./usr/share/doc/libvlc-dev/examples/gtk_player.c
-rw-r--r-- root/root     13034 2024-06-05 18:56 ./usr/share/doc/libvlc-dev/examples/libvlc_DVD_ripper.c
-rw-r--r-- root/root      6572 2024-06-05 18:56 ./usr/share/doc/libvlc-dev/examples/vlc-thumb.c
-rw-r--r-- root/root      8795 2024-06-05 18:56 ./usr/share/doc/libvlc-dev/examples/wx_player.cpp
lrwxrwxrwx root/root         0 2025-10-21 22:36 ./usr/lib/x86_64-linux-gnu/libvlc.so -> libvlc.so.5.6.1

Если вы не работали с Linux вам будет, думаю трудно. Но в целом, смысл в том, что при установке программ исполняемые файлы и библиотеки раскладываются по файловой системе, в частности библиотеки в /lib, /usr/lib, /usr/share/lib*.

А заголовочные файлы с описанием функций и классов - в /usr/include и прочие директории «*/include».

Для использования библиотеки при сборке вашего приложения нужно подключить соответствующий заголовочный файл в исходном коде вашего приложения через директиву #include. Если говорить о libvc-dev из директории /usr/include/vlc.

И только так, потому как потом ld-linux будет искать библиотеки для запуска вашего приложения в системных директориях, а не рядом с исполняемым файлом.

Т.е. ничего класть рядом не нужно. В Linux есть программа ld-linux, которая на основе директорий поиска библиотек в своей конфигурации осуществляется динамическое связывание и загрузку нужных библиотек при запуске соответствующей программы или вызове из одной библиотеки функции другой.

В целом, почитайте как собирать программы и подключать заголовочные файлы ( include ) в C и C++.

Так же в Astra Linux вы можете запросить дистрибутив для разработчиков бесплатно, получите установочный комплект, диск с дополнительными пакетами и диск с пакетами для разработки (сборки программу) и документацией.

Пакеты с суффиксом «-dev» нужны только для сборки программ, для работы не требуются.

В Astra из коробки может быть предустановлен vlc, но не libvlc-dev, да и рассчитывать что хотя-бы что-то будет предустановлено - не очень.

Это чушь какая-то. Если вы предполагаете сборку вашего ПО на целевых машинах - очень спорное решение.

Одним из требований проекта является оффлайн установка.

Пожалуйста - собираете deb пакет и указываете корректно зависимости. Которые можно поставить оффлайн с DVD диска Astra Linux.

Делать по другому не советую, потому как вы можете столкнуться с разными версиями, условно 1.7.0, 1.7.1, 1.7.2 и так до 1.7.9 для Astra Linux SE 1.7 и с разными версиями для Astra Linux SE 1.8.

Это если не брать старые версии.

Если вы будете поставлять ваше приложение с so файлами от несовместимой версии Astra с той, куда ставится либо ваше приложение будет работать нестабильно, либо могут быть в целом проблемы в работе системы.

Поэтому в идеале сборка отдельной версии вашей программы под окружение конкретной версии и в идеале в виде DEB пакета с зависимостями, которые должны подтягиваться с официального репозитория, либо с установочного диска дистрибутива.

Ни в коем случае не пытайтесь подсовывать DEB пакеты, скажем от Debian или Ubuntu.

Почитайте темы на форуме, где в Ubuntu подключили репозитории Debian, Mint причём разных поколений дистрибутивов и сломали систему.

Если уж очень хочется и по другому никак - то собираете ваше приложение так, чтобы оно ставилось и искало свои файлы и библиотеки относительно /opt ли /usr/local.

Т.е. в

• /opt/bin/ваша_программа - исполняемый файл
• /opt/lib - библиотеки вашей программы
• /opt/share - прочие файлы вашей программы
• /opt/var - изменяемые данные вашей программы

Это должно быть настроено корректно в сборочном окружении.

Вот здесь косвенно можно класть свои библиотеки, но в целом не рекомендуется.

Правильный подход - сборка под конкретный релиз дистрибутива набора DEB пакетов, в которых корректно указаны DEB-пакеты - зависимости из официального репозитория дистрибутива в Internet или на DVD диске.

В случае Astra SE можно и так и так.

Вот содержимое пакета с библиотекой libvlc5:

dpkg-deb -c libvlc5_3.0.21-0astra2+b3_amd64.deb
drwxr-xr-x root/root         0 2025-10-23 12:50 ./
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/lib/
drwxr-xr-x root/root         0 2025-10-23 12:50 ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root    154104 2025-10-21 22:36 ./usr/lib/x86_64-linux-gnu/libvlc.so.5.6.1
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/bug/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/bug/libvlc5/
-rw-r--r-- root/root       292 2022-11-23 21:49 ./usr/share/bug/libvlc5/control
-rw-r--r-- root/root      1156 2022-11-23 21:49 ./usr/share/bug/libvlc5/presubj
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/doc/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/doc/libvlc5/
-rw-r--r-- root/root       206 2025-10-21 22:36 ./usr/share/doc/libvlc5/changelog.Debian.amd64.gz
-rw-r--r-- root/root      3205 2025-10-21 22:36 ./usr/share/doc/libvlc5/changelog.Debian.gz
-rw-r--r-- root/root     70963 2024-06-05 18:57 ./usr/share/doc/libvlc5/changelog.gz
-rw-r--r-- root/root     59112 2022-12-06 01:04 ./usr/share/doc/libvlc5/copyright
lrwxrwxrwx root/root         0 2025-10-21 22:36 ./usr/lib/x86_64-linux-gnu/libvlc.so.5 -> libvlc.so.5.6.1

Именно с этой библиотекой (/usr/lib/x86_64-linux-gnu/libvlc.so.5) должна быть слинкована ваша программа, а в зависимостях DEB пакета с ней должен быть указан пакет c libvlc5:

Depends: libc6 (>= 2.4), liblc5 (>= 3.0.21)

Приложение мы упаковываем в deb пакет сами, сборка у клиента не предполагается, а наш установщик - лишь мордочка для отображения процесса установки (тоже на avalonia), под капотом просто вызываем dpkg -i и показываем некоторую информацию, по аналогии инсталлятора создаваемого через innosetup на Windows. Необходимость в такой мордочке появилась потому что собранный deb пакет весит довольно много (несколько Гб) и графическая оболочка для установки deb пакетов в астре из-за этого открывается очень долго (мы не рассчитываем что клиент будет ставить что-то через терминал, т.к. он точно также вынужденно переходит с Windows, а там он привык к обычному инсталлятору)

То что нужные нам пакеты есть в репозитории астры мы знаем, собственно оттуда мы их и выкачивали.

Собственно примерно к тому же мы и пришли - вписать в требование доступ к репозиторию астры (будь то диск или онлайн) чтобы нужные зависимости установились оттуда.

По поводу того что libvlc-dev только для разработки - мы следовали этому руководству https://github.com/videolan/libvlcsharp/blob/3.x/docs/linux-setup.md

Возможно dev библиотека действительно не нужна и необходима лишь какие-то ее зависимости, но только с установленным из коробки vlc ПО не запускалось

В libvc-dev содержится символьная ссылка:

./usr/lib/x86_64-linux-gnu/libvlc.so -> libvlc.so.5.6.1

В инструкции в git репозитории сказано:

For ubuntu:

sudo apt install libvlc-dev.

libvlc.so and libvlccore.so will be located at /usr/lib

А если вы всё же внимательно прочитаете написанный текст, то:

Вот содержимое пакета с библиотекой libvlc5:

dpkg-deb -c libvlc5_3.0.21-0astra2+b3_amd64.deb
drwxr-xr-x root/root         0 2025-10-23 12:50 ./
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/lib/
drwxr-xr-x root/root         0 2025-10-23 12:50 ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root    154104 2025-10-21 22:36 ./usr/lib/x86_64-linux-gnu/libvlc.so.5.6.1
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/bug/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/bug/libvlc5/
-rw-r--r-- root/root       292 2022-11-23 21:49 ./usr/share/bug/libvlc5/control
-rw-r--r-- root/root      1156 2022-11-23 21:49 ./usr/share/bug/libvlc5/presubj
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/doc/
drwxr-xr-x root/root         0 2025-10-21 22:36 ./usr/share/doc/libvlc5/
-rw-r--r-- root/root       206 2025-10-21 22:36 ./usr/share/doc/libvlc5/changelog.Debian.amd64.gz
-rw-r--r-- root/root      3205 2025-10-21 22:36 ./usr/share/doc/libvlc5/changelog.Debian.gz
-rw-r--r-- root/root     70963 2024-06-05 18:57 ./usr/share/doc/libvlc5/changelog.gz
-rw-r--r-- root/root     59112 2022-12-06 01:04 ./usr/share/doc/libvlc5/copyright
lrwxrwxrwx root/root         0 2025-10-21 22:36 ./usr/lib/x86_64-linux-gnu/libvlc.so.5 -> libvlc.so.5.6.1

То увидите следующее:

• /usr/lib/x86_64-linux-gnu/libvlc.so.5.6.1
• /usr/lib/x86_64-linux-gnu/libvlc.so.5 -> libvlc.so.5.6.1 - есть в libvlc-bin
• /usr/lib/x86_64-linux-gnu/libvlc.so -> libvlc.so.5.6.1 - есть в libvlc-dev

Т.е. в конечном итоге программа будет использовать библиотеку ./usr/lib/x86_64-linux-gnu/libvlc.so.5.6.1 или /usr/lib/x86_64-linux-gnu/libvlc.so.5

Поправьте зависимости библиотек в исходных кодах иностранного ПО, чтобы оно было слинковано в итоге не просто с /usr/lib/x86_64-linux-gnu/libvlc.so, а с /usr/lib/x86_64-linux-gnu/libvlc.so.5.

Они обе являются символьной ссылкой:

 * (есть в libvlc-bin) /usr/lib/x86_64-linux-gnu/libvlc.so.5 -> /usr/lib/x86_64-linux-gnu/libvlc.so.5.6.1
 * (есть в libvcl-dev) /usr/lib/x86_64-linux-gnu/libvlc.so -> /usr/lib/x86_64-linux-gnu/libvlc.so.5.6.1

Т.е. и libvlc.so и libvlc.so.5 указывают на одну библиотеку.

Линкуйте с libvlc.so.5.

Библиотека /usr/lib/x86_64-linux-gnu/libvlc.so.5.6.1 как раз в пакете libvlc-bin и символьная ссылка

/usr/lib/x86_64-linux-gnu/libvlc.so.5 -> /usr/lib/x86_64-linux-gnu/libvlc.so.5.6.1

Вообще, так подумать, выглядит странно, вы собираете иностранное ПО, видимо, даже без понимания что делаете и как оно работает. Не мне вас судить, но лично на мой субъективный взгляд всё это очень странно.

Помещать гигабайты в один deb пакет, тоже не очень хорошо. Разбейте сборку на несколько deb пакетов и будет счастье, к тому же это по идеологии Linux правильно.

С таким подходом к разработке они не пройдут сертификацию и «Astra Ready».

/opt/bin/ваша_программа - исполняемый файл /opt/lib - библиотеки вашей программы /opt/share - прочие файлы вашей программы /opt/var - изменяемые данные вашей программы

В /opt же вроде по-другому нужно:

/opt/ваша_программа, и внутри уже можно bin, lib, share, var и т.д.

То есть, не /opt/bin/ваша_программа, а /opt/ваша_программа/bin и т.д.

На всякий случай упомяну, что apt тоже умеет устанавливать из локальных .deb файлов и, в отличие от dpkg -i, умеет скачивать к ним зависимости (если репозиторий доступен):

apt install ./filename.deb
apt install /path/to/filename.deb

Так что если хочешь делать dpkg -i libvlc, то сначала лучше попробовать сделать просто apt install ./твоя_программа.deb - в большинстве случаев всё получится, потому что интернет обычно всё-таки есть (либо диск), а ещё может быть эти пакеты уже установлены почему-то. Вот если не получилось - уже дальше варианты, либо ругаться и прекращать работу, либо рискованно ставить собственные оффлайн-пакеты (только для начала надо ещё выяснить список того, что не хватает). Что касается -dev пакета, то он и правда не должен быть нужен для работы.

Прижали виндузятников, заставили учиться программировать.

У тебя есть два пути:

1. Делать сборку под каждый дистрибутив, который тебе может встретиться. Тогда рассчитывай на наличие там libvlc, но только вот непонятно, откуда у тебя там взялся libvlc-dev, если он нужен только при компиляции. Предполагаю, что ты не сможешь ответить на вопрос, зачем тебе окружение сборки при инсталяции на целевом компе

2. Делать универсальную сборку, собирать свой libvlc и всё прочее, кроме glibc. Мы идем именно по этому пути, но у нас нет десктопа, а у вас скорее всего есть. В любом случае надо тестить в докере под разными линуксами, что там будет на инсталяции и будет ли оно запускаться.

Разрабатываем ПО для AstraLinux. До этого проекта никто из разработчиков не имел не то что опыта разработки под Linux, но и опыта взаимодействия с ним.

И ни у кого не ёкнуло, что что-то здесь на организационном уровне явно не так?

в большинстве случаев всё получится, потому что интернет обычно всё-таки есть

Если у них закрытый контур, то нет.
А требование оффлайн установщика как бы а это явно намекает. Хотя тут может ноги у него растут из виндового прошлого, конечно.

(мы не рассчитываем что клиент будет ставить что-то через терминал, т.к. он точно также вынужденно переходит с Windows, а там он привык к обычному инсталлятору)

Это неправильный путь.

а наш установщик - лишь мордочка для отображения процесса установки (тоже на avalonia), под капотом просто вызываем dpkg -i и показываем некоторую информацию, по аналогии инсталлятора создаваемого через innosetup на Windows.

Не надо так делать. Юзеры спасибо не скажут. Делайте просто deb — единообразие намного важнее вымышленного псевдоудобства.

Найдите по близости, любого, любителя дебианщиа/цу, может это будет у вас слесарь, уборщица, повариха, водитель. И они вам с радостью расскажут, что такое пакетные системы, зачем они нужны и как в них влезать, или как с ними жить рядом, и почему именно так. Проконсультируют и увлекательно с энтузиазмом расскажут.

может использовать статическую линковку, потом можно сделать свой инсталлятор типа install.bin, но на него нужно будет выдавать флаг chmod +x install.bin

и что? Какие есть силы, такие и используют.

Или ты предлагаешь всё бросить?

Ну, я бы предложил задуматься над тем, чтобы найти хотя бы одного или двух людей, кто в теме. Иначе получится, мягко говоря, фекалии, начало чего мы и наблюдаем в треде. А потом мы же здесь же будем орать, что импортозамещение провалилось, и разработчики дегенераты (я не про ТСа конкретно, а про абстрактную импортозамещённую поделку).

Для конечной системы:

Самый надёжный путь (хоть и не самый удобный для эникеев на той стороне трубы, но это как раз тот случай, когда свинки должны быть подавлены) – прописать в документации, что перед установкой вашего ПО требуется установить следующие пакеты с официального диска AstraLinux (точный список прилагается). ГОСТ 19.502-78, Описание применения, раздел «Условия применения».

Далее есть нюансы. Если вашему продукту требуется сертификация (МО, ФСТЭК, персональные данные и т.д.) – диском полагается и ограничиться. Если сертификация не нужна, но нужна именно Астра – помимо диска можно воспользоваться русбитеховским расширенным репозиторием (всё, разумеется, должно быть документировано). Где взять расширенный репозиторий – пинайте техподдержку Астры (да, это как раз тот случай, когда общаться надо с ней, а не с ЛОРом).

Включать же астровские системные пакеты в свой дистрибутив – плохая идея сразу по нескольким причинам. Начиная от неочевидных организационно-юридических нюансов, в которые я даже лезть не хочу, и заканчивая вполне очевидным фактом, что Астра периодически своим пакетам устраивает обновления безопасности.

Для разработки:

Реальны ли вообще оффлайн установщики при разработке под Linux для ПО, требующего сторонних зависимостей?

Да, называется «развёртывание локального репозитория». Описано в куче ресурсов по дебианоподобным дистрибутивам, в том числе, внезапно, на сайте Астры, надёжнее всего именно оттуда и брать. (Только этих инструкций там несколько под разные версии, могут отличаться путями.)

До этого проекта никто из разработчиков не имел не то что опыта разработки под Linux, но и опыта взаимодействия с ним.

разработчиков

но и опыта взаимодействия с ним

разработчиков

2026 год

разработчиков

А вот здесь очень хочется ответить не очень цензурно. На дворе 2026 год, куда всё катится, умные разработчики просекли уже 12 лет как, не очень умные, но хоть сколько-нибудь приличные – 4, дальновидные… ну лет 20, например. Ладно, лучше поздно, чем никогда.

В крайнем случае, компилируйте всё статично, кроме libc, но можно и её впаять и устанавливайте всё в /opt

сделать deb пакет где все нужное запихать в /opt/super-puper-proga и больше ничего никуда не пихать и не просить в систему установить.

а за левые инсталяторы - оторвать руки

Надо засунуть всю свою программу в какой-нибудь /opt/mysoft и туда же засунуть этот ваш LibVLCSharp, с которым и линковаться. Т.е. вообще не требовать и никак не взаимодействовать с системным пакетом libvlc-dev. Или вообще статически слинковаться, если получится.

В целом принцип безгеморройной разработки под линукс простой - чем меньше зависишь от дистрибутива, тем лучше. Зависимости по максимуму надо носить с собой. Потому, что дистрибутивописатели обновят эту библиотечку, ваша программа сломается из-за них, но пользователи жаловаться будут именно на вас.

слушай, ну если виндузятники считают себя разработчиками, то лучше особо не спорь, они и считают то с трудом.

для этого и создавали пакеты «виртуализации приложений» :) snap appimage flatpack и иже с ними :)

Flatpak, snap это для изоляции приложений от системы. Цель тоже полезная, но в данном случае топикстартеру нужно не это.

AppImage условно про это, но я смысла в этой технологии не увидел. Папка с файлами прекрасно работает, зачем её засовывать в какие-то архивы - не понимаю.

для зависимостей от других пакетов есть параметры деб-пакета Depends Pre-Depends Recommends Suggests.
с ними любой сторонний деб пакет прекрасно ставится.
просто после установки пакета требуется доустановить зависимости apt install -f сколь помню.
множество пакетов у меня так установлены (ну бубунте правда).
ну и мейнтейнер пакета должен тестировать работоспособность каждого выпущенного пакета со всеми зависимостями.

не только. пакеты не только изолированы от системы но и «всё свое должны носить с собой».
потом конечно появились зависимости, ибо без них очень тяжелые сборки получались.
смысл был в полной отвязке от системы (это и есть «виртуализация приложения»), скачал пакет и он заработал, без всяких там «library hell» и прочия.

Единственный корректный подход, это складывать всё в /opt/my-software/. Все зависимости. Всё. Желательно еще и линковать всё статически.

Всё. Других нормальных способов распространения своего ПО, особенно проприетарного, в красноглазии нет.

Дело не в импортозамещении, а в том что линукс и родственники - крайне плохо созданы для распространения проприетарного, или вообще, своего, софта, особенно клиентского.

Я с этими же проблемами, и еще хуже, сталкивался когда работал в одной крупной компании, где надо было делать клиент на кучу разных дистрибутивов.

Вся FHS итп помойка сразу идет к херам.

Только свой установщик, только статическая линковка, и только в свою директорию, вон в /opt куда-то.

Это не крайний случай, это единственное вменяемое решение.

Неправильный подход.

В сертифицированных дистрибутивах должен использоваться только сертифицированный софт.

А если есть внешний софт - он должен максимально использовать системные библиотеки, т.е. фактически собираться пакет только с бинарниками самого софта и конкретно его библиотек, всё остальное в зависимостях пакета к пакетам в репозитории.

В идеале софт тоже должен пройти сертификацию.

только статическая линковка

Это возможно.

где надо было делать клиент на кучу разных дистрибутивов.

Это вопрос оптимизации исходного кода под разные окружения и сборки тоже.

К примеру 1С выпускает версию PostgreSQL-1C под разные версии дистрибутивов в виде пакетов.

Так что правильный подход - собирать и опакечивать софт под соответствующий дистрибутив и его версии (релизы).