OberonCore

Что из этого будет дорабатываться, а что - так и задумано?

1. После установки пакета, проект всё ещё не готов к прямому использованию, так как исполнимые файлы находятся в каталогах не из стандартного PATH
2. Установка производится не в /usr/bin, а в /usr/local/bin
3. Зависимости не прописаны, то есть может понадобиться что-то доустанавливать.
4. При удалении пакета установщик демонстрирует желание удалить /usr/local/bin "dpkg: предупреждение: при удалении multioberon каталог «/usr/local/bin» не пуст, поэтому не удалён"

1. Да, так и задумано. Во-первых, нужно создать рабочую папку. Во-вторых, могут быть одновременно установлены и 32-бит, и 64-бит.
2. Да, предпочитаю /usr/local/bin
3. Зависимостей от пакетов нет. LLVMT и хвосты я прикладываю. А вот версии glibc имеют значение.
4. Не наблюдал, не готов сказать, приму к сведению.

Тогда, наверно, snap или flatpak больше подходят - и проще собирать и сразу для многих систем

1. "Работоспособно после установки" принципиально неприемлемо как с Go(не совсем) или есть сложности с воплощением?
2. Что насчёт предпочтений пользователей ? /usr/local предусмотрен для установок мимо пакетов, например через make. Может возникнуть путаница.

Дело не в наличии или отсутствии работоспособности, а в необходимости установки рабочего каталога (как с Go). На сегодня такая схема. Она сможет поменяться, если, например, будет какой-то внутренний пакетный менеджер (из BlackBox, или как в Go).
Сейчас, например, для автономной, без BlackBox, инсталляции нужно где-то помещать System, Host. Их нужно откомпилировать, чтобы с ними работали другие пакеты. Это делает установщик рабочего каталога.
Даже, если установка с BlackBox, пакеты System, Host нужны для Omf, Oml.

Я воспринял Ваше предложение.
Просто, когда делаешь "производственную" разработку, есть 2 момента:
1). Система управления требованиями;
2). Система интеграции и тестирования.

В части 1) я, естественно, руководствуюсь своими требованиями и предпочтениями. Для меня работа через пакеты - однозначно неудобна, т.к. я работаю через кучу виртуалок, и не всегда знаю пароли. Поэтому распаковать zip и запустить скрипт - самое то. А вот на домашнем Raspberry PI - да, такая инсталляция хороша. Я буду иметь в голове "предпочтения пользователей"

В части 2) в обычной жизни я сборку и интеграцию сам не делаю, поручаю сотрудникам, которые этим занимаются. Поэтому глубокого мнения, что хорошо, что плохо, не имею. Однако, некоторые вещи я не хочу делать, как в Линуксе. Например, возьмем программу dpkg
- бинарники /usr/bin/dpkg
- конфигурация /etc/dpkg/
- еще конфигурация /var/lib/dpkg
Я прекрасно понимаю, что люди, которые это делали, имеют свои на то основания. Плюс, когда 2000 пакетов, тут нужны глобальные правила. Но уж больно расплодилось: Red Hat - одно, debian - другое, а еще Astra Linux, Alt Linux, ...

Поэтому и была идея сделать минимум в компактной локации /usr/local/bin.

Спасибо, а то непонятно, куда выкладывать.

К сожалению, не получилось это сделать. Две попытки выложить бинарные файлы release были оборваны github без возможности повторной закачки. Увы, эти мэйнстримные средства, на которые весь мир сажают для т.н. "профессиональной разработки", работают нестабильно, только время зря потратил. На mail.ru выложил без проблем, интернет стационарный, домашний.

Ну и, отвлекусь, работая по созданию пакетов msi в продукте Wix, снова ощутил весь ужас этих продуктов больших компаний. Становится понятно, почему люди полюбили Python...


Ну, если Иван Андреевич окажет любезность и скопирует, будет хорошо.

Можно следовать общим правилам, например, https://refspecs.linuxfoundation.org/FH ... index.html

Стандарт плохой, но лучше, чем 1000 хороших(не точно) стандартов

Среди пакетов тоже есть стандарт - rpm. Я уже упоминал об этом. Его можно поставить и на .deb системах через alien. Единственно, теряются зависимости, но для вашего пакета это не актуально.

Всё больше к тому, что Вам больше подходят пакеты нового типа - snap, flatpak

Плохо, что не удалось. mail.ru как и yandex у большого количества людей заблокирован, да и скачивать не так удобно как с прямой ссылкой.

Сегодня удалось опубликовать Release https://github.com/dvdagaev/Mob/releases/tag/v1.1.0. Ссылки на mail.ru оставил как зеркало в README.

Я хожу через плагин Yandex Access, ставится с Google-магазина. Пускает на mail.ru и на Yandex, а также в ВК и ОК.

Это да.

Есть ещё заслуженный Dropbox.

Если не секрет, кто "hardware"?

Raspberry Pi 4 с осями:
- Raspberry Pi OS ArmV71 (32-бит);
- Linux Ubuntu Arm64 (64-бит).

Yeeesss!
На RPi3B попробую, когда openSUSE укрощу.