LINUX.ORG.RU

Как правильно запаковать проект?

 , ,


1

1

Некоторое время назад приходил сюда просить для своего проекта дампы dmidecode с реального железа. Спустя почти год проект прошёл путь от 0.1 до 0.5.1 и превратился из простого аналога dmidecode во что-то большее:

  • Имеет в базе движок на C, который предоставляет прямой доступ к типизированным данным по полям, причём кодеки в движке описываются декларативно
  • Декодирует гораздо больше структур, чем описано в спецификации, и даже гораздо больше, чем dmidecode. Многое пришлось реверс-инжинирить руками, зато теперь декодируются даже таблицы Intel vPro, FVI, AMT, MEI, SVT и так далее - даже если они перенесены на другие ID
  • Умеет определять таблицы не только по коду, но и по сигнатурам, есть платформно-зависимые модули (Acer, Dell, HP, Lenovo, AMI и так далее), auto-probing и т.п.
  • Умеет в string properties у таблиц, vendor-specific релокацию ID типов таблиц и даже бинарные оверлеи (additional information из SMBIOS specification)
  • Умеет проверять дампы своим линтером с кучей правил
  • Умеет экспортировать дампы в XML, JSON и YAML и даже анонимизировать их при сохранении
  • Имеет большой задел под компилятор прошивок SMBIOS (из YAML, JSON или XML), который может пригодиться OEM
  • Работает на Linux, FreeBSD, NetBSD, macOS и Windows

Ну и сайт и документацию как на библиотеку, так и на CLI наконец сделал. В ближайших релизах после некоторой стабилизации хочу прикрутить нативное API для C++, модуль ядра, который бы вытаскивал всё это добро на SysFS для удобства использования из скриптов, потом - API для Python, Go и Rust.

Собственно, вопрос: сейчас это всё собирается CMake с исходников на GitHub. Как лучше сделать пакеты для Linux, чтобы это можно было устанавливать без плясок с бубном, куда их лучше класть (в стандартные репы фиг прорвёшься) и вообще чего ещё хотелось бы от user experience такой штуки? Как лучше проводить тестирование, т.к. очевидно, что у реальных пользователей будут вылезать баги, где их брать в мире open-source?

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

Собственно, вот: https://opendmi.org/

Заранее спасибо!

Перемещено hobbit из general


Ответ на: комментарий от mord0d

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

sdnvx
() автор топика

Ну что вам сказать, я попробовал собрать.

  1. билдеры пакетов как правило не имеют интернета, поэтому fetch cmocka не прокатывает. 1.1 лично у меня даже просто выкачать https://cmocka.org/files/2.0/cmocka-2.0.2.tar.xz не получается без VPN. 1.2 Конечно это обходится все подкладываем архива в нужное место, но я в данном случае увидеть не могу т.к. cmake висит на ожидании скачивания cmocka а оно не качается (см. 1.1)
  2. неплохо бы опцию SYSTEM_CMOCKA и использовать системную либу.

in progress…

irton ★★★★★
()
Последнее исправление: irton (всего исправлений: 2)

Собственно, вопрос: сейчас это всё собирается CMake с исходников на GitHub.

Так и надо.

Как лучше сделать пакеты для Linux, чтобы это можно было устанавливать без плясок с бубном, куда их лучше класть (в стандартные репы фиг прорвёшься) и вообще чего ещё хотелось бы от user experience такой штуки?

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

anonymous
()

чтобы это можно было устанавливать без плясок с бубном, куда их лучше класть

appimage и все библиотеки с собой

thunar ★★★★★
()
Ответ на: комментарий от anonymous

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

А вот и нет! Мне, как мейнтейнеру, чтобы понимать надо оно мне опакечивать и поддерживать, или нет, вначале надо потыкать в готовое. А когда оно уже будет в основных дистрах — тогда можно и убрать лишнюю сущность в виде пакетов на гитхабе.

mord0d ★★★★★
()
Ответ на: комментарий от anonymous

Поддерживаю этого анонимуса. Главное, чтобы были сорцы и бинари в tar.xz. А дальше уже только донести свой софт до пользователей. Или через рассылки(как выше говорили), или через форумы, как здесь. Мантейнеры твой пакет не возьмут. А если ты лично будешь собирать пакеты, ты берёшь на себя обязанность мантейнера. Т.е. помимо поддержки разработки и исправления багов, тебе придётся следить за всеми изменениями в пакетировании. Я, конечно, могу подробнее рассказать, как собирать и deb, и rpm. Или даже написать базу для deb и rpm. Могу и ebuild для gentoo написать. Но я ничерта не смыслю конкретно в твоей области. Как вариант, можно попробовать связаться с мантейнерами(это не всегда один человек, иногда это команда) dmi-пакетов в основных дистрах. Опять же, немного не моя область.

Ну и конечно скрипты из cmake лучше убрать. Такое не любят не только мантейнеры, такого не любит никто.

shell-script ★★★★★
()
Ответ на: комментарий от irton

Спасибо огромное! Я понял примерный вектор движения. Вчера выпустил 0.6 с кучей стабилизирующих изменений, поддержкой SMBIOS 3.10 и –no-pager, к 0.7 причешу CMake, скрипты и всё вот это.

sdnvx
() автор топика
Ответ на: комментарий от bbc69

Простыни обычное дело, оно на типовом железе вываливает скринов 20-30 инфы, поэтому сделал просто --no-pager в качестве глобальной опции

sdnvx
() автор топика
Ответ на: комментарий от sdnvx

может еще переменную окружения добавить типа NO_PAGER?

Странно что еще не появилось боле-менее стандартного варианта по аналогии с NO_COLOR после внезапно появившейся любви у разработчиков самим заворачивать в пейджер когда их не просят (systemd с пример ужасного подхода к этому, хотя вроде ща уже лучше стало)

user_undefined ★★
()
Ответ на: комментарий от user_undefined

Не очень понятно, зачем нужна такая переменная окружения, когда можно сделать просто unset $PAGER. Он же включается только если установлен $PAGER

sdnvx
() автор топика
Ответ на: комментарий от user_undefined

заворачивать в пейджер когда их не просят (systemd с пример ужасного подхода к этому, хотя вроде ща уже лучше стало)

А что в этом такого плохого?

vbr ★★★★★
()
Ответ на: комментарий от sdnvx

unset - влияет даже там, где он нужен, и поломает | $PAGER. отдельная переменная будет влиять на внутреннее поведение конкретного приложения там, где это опционально.

user_undefined ★★
()
Ответ на: комментарий от vbr

ну я вот предпочитаю сам контролировать нужен мне пейджер или нет. Я не предлагаю менять дефолт, я предлагаю добавить возможность отключить пейджер, без постоянного вспоминания как отключить это в конкретной программе (–no-pager ли –nopager, не забыть -l добавить для системд).

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

user_undefined ★★
()
Ответ на: комментарий от user_undefined

Я всё ещё не понимаю логики, зачем делать NO_PAGER, чтобы потом делать | $PAGER. Возможно, я тупой и не учитываю каких-то кейсов :)

sdnvx
() автор топика
Ответ на: комментарий от user_undefined

Можешь добавить |cat к любой программе и гарантированно не получить пейджер (:

vbr ★★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария