= Сообщение: 544 из 3148 ================================== RU.LINUX.CHAINIK = От : Alexander Polozov 2:5025/3.167 20 Oct 14 07:40:04 Кому : Serguei E. Leontiev 20 Oct 14 07:40:04 Тема : разработка под эхотаг FGHI : area://RU.LINUX.CHAINIK?msgid=2:5025/3.167+54448700 На : area://RU.LINUX.CHAINIK?msgid=<1187496600@ddt.demos.su>+c5c3eae2 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Привет, Serguei!
Ответ на сообщение Serguei E. Leontiev (2:5020/400) к Alexander Polozov, написанное 19 окт 14 в 18:52:
JA>>>>> Ты не понял. Я про дистрибутив своего приложения. JA>>>>> Или как в Линуксе называется комплект файлов, JA>>>>> установив который в целевой системе я получу JA>>>>> работающее свое приложение? AV>>>> Это называется "пакет" ("package"). Hо для своей работы AV>>>> софт в этом пакете потребует установки других пакетов - AV>>>> от ядра до распоследней библиотеки. JA>>> Вот все необходимое я и хочу запихать в этот пакет. AP>> Это порочный путь (им в основном пользуются для распространения AP>> проприетарного говна дабы исходники не открывать). AP>> В линухвее же принято в пакет запихивать только свою софтину, AP>> все необходимые внешние либы прописываются в зависимостях, AP>> разгребание зависимостей уже ложится на плечи пакетного AP>> менеджера.
SL> Реклама, сэр. Так, более или менее, получится делать для LSB SL> совместимых систем (Linux Standard Base, ISO/IEC 23360), и то только SL> для зависимостей от библиотек из LSB.
SL> Если же использовать библиотеки, которые не входят в LSB, то SL> вариантов, по большому счёту, два, либо включать их свой(и) RPM и SL> ставить их согласно FHS в /opt/<зарегистрированное имя SL> производителя>/... (Filesystem Hierarchy Standard, часть LSB, но SL> признаваемая более широко), либо последовательно убеждать SL> разработчиков дистрибутивов Linux, что их пользователям твой пакет SL> нужен, полезен и им стоит самим с ним мучиться и включать в свои SL> дистрибутивы. Ну не знаю зачем такие извраты. В том же gentoo вопрос решается довольно тривиально. Создаём пакет (клепаем ebuild) для софтины, все внешние библиотеки пишем в зависимости и если их нет в основном дереве создаём пакеты и для них. И если по каким то причинам не получается всё это добро пропихнуть в основное дерево - поднимаем локальный оверлей. Для пользунов подключение нашего оверлея (в зависимости от кривизны наших рук) строчка в конфиге или просто одна команда. Насколько я ничего не знаю в более/менее вменяемых дистрах вопрос также решается через локальные репозитории.
AP>> Сложность в том что, в отличие от винды, в линухах пакетных AP>> систем много и они между собой не совместимы. Hапример даже в AP>> среде RPM-based систем не каждый RPM-бандл от Сьюзи взлетит на AP>> Федоре и наоборот. Придётся либо самому делать пакеты для, хотя AP>> бы, основных дистрибутивов, либо сотрудничать с мантейнерами AP>> оных.
SL> Время шепчет, что для этих Linux shell-овский архив это самое простое SL> и самое надёжное решение, или tar архив иерархии SL> /opt/<зарегистрированное имя производителя>/... со скриптом установки SL> и удаления. Самое простое и надёжное раздавать в сорцах+пакет для своего личного дистра. Тогда, если софтина востребована, завсегда найдётся человек способный собрать пакет для своего дистра.
Для примера могу привести rusXMMS. Там помимо основной либы куча вспомогательных + патчи для многих пакетов. Товарищ умудряется поддерживать в актуальном состоянии пакеты для кучи дистров + оверлей для gentoo.
Со всеми пожеланиями, Alexander Polozov
... CPU not found, software emulation... --- GoldED+/LNX 1.1.5 (Linux 3.16.0-pf2 CPU UNKNOWN) * Origin: Пьяную девушку проще довести до оргазма, чем до дома (2:5025/3.167)
