The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск пакетного менеджера RPM 4.16, opennews (ok), 30-Сен-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


67. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от Аноним (-), 01-Окт-20, 13:01 
Вспомнил. В 1990-х гг. RPM называли примитивным, когда сравновали его с пакетным менеджером Debian-а.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

83. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:14 
> В 1990-х гг. RPM называли примитивным, когда сравновали его с пакетным
> менеджером Debian-а.

Он не примитивный, он дубовый.  А дебиановский по жизни называют результатом оверинжиниринга, хотя если посмотреть, когда там появились подписи -- то и в "овер-" можно было усомниться.

У каждого из них есть свои плюсы и минусы, при этом rpm тяготеет именно к дубовому краю шкалы, а dpkg -- к гибкому (дальше тот же портадж).

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

Ответить | Правка | Наверх | Cообщить модератору

88. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от Аноним (86), 01-Окт-20, 15:19 
> Он не примитивный, он дубовый.  А дебиановский по жизни называют результатом оверинжиниринга

Кто называет? Вообще-то всё ровно наоборот.

Ответить | Правка | Наверх | Cообщить модератору

131. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от mikhailnov (ok), 02-Окт-20, 00:42 
Не похожа сборка deb на гибкую. Ни макросов и env, ни генераторов зависимостей и провайдов.
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

133. "Выпуск пакетного менеджера RPM 4.16"  –3 +/
Сообщение от Аноним (86), 02-Окт-20, 00:59 
Сборка deb — гибче некуда. Хочешь — руками архивы пакуй (ничего, кроме текстового редактора, tar и ar не надо), хочешь — скрипт напиши, хочешь — для облегчения задачи возьми dpkg-deb вместо архиватора, хочешь — используй dpkg-buildpackage, который запускает самый обычный make, для которого ты волен задавать какие тебе вздумается правила. Вместо макросов — вспомогательные утилиты для вызова из make-файла (прежде всего, конечно, dh, но не только; можешь сам скрипт написать и оттуда дёргать). Что ты подразумеваешь под env — в душе не чаю. Генераторы зависимостей есть. Генераторов провайдов нет, потому что там просто не принято пихать по сотне провайдов в пакет, вместо этого генераторы зависимостей более умные (находят не только нужный файл, но и пакет, к которому он принадлежит, и прописывают его явно).
А вот в rpm гибкости нет. Кроме rpmbuild ничем пакет не сделать. Никак кроме спека rpmbuild'у правила сборки не задать. В итоге, конечно, полному нубу намного легче освоить сборку rpm, но к гибкости это отношения не имеет.
Ответить | Правка | Наверх | Cообщить модератору

135. "Выпуск пакетного менеджера RPM 4.16"  –3 +/
Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:09 
> Сборка deb — гибче некуда.

Заметьте вот это враньё.

> Вместо макросов

То есть даже макросов нет?

> Генераторы зависимостей есть. Генераторов провайдов нет

То есть и генераторы зависимостей наполовину лишены смысла (например, на сошки или .pm-ки).

> А вот в rpm гибкости нет. Кроме rpmbuild ничем пакет не сделать.

Так и тарбол руками вряд ли соберёте.

> Никак кроме спека rpmbuild'у правила сборки не задать.

Вы вообще не в теме, поэтому и пытаетесь пнуть куда попало.

RPM -- точнее, конкретно rpmbuild, это сильно отдельная программа и вполне заменимая чем-либо, что понадобится иного -- не туда пинать надо, что "фуу, без makefile этот ваш make бесполезен".  А в то, что -- в отличие от make -- синтаксис спека является ad hoc и не подлежит описанию формальной грамматикой, что исключает возможность автоматического валидирования (да и полноценный разбор подразумевает возможность исполнения произвольного кода, хотя в частных случаях с этим кое-что получается сделать).

> В итоге, конечно, полному нубу намного легче освоить сборку rpm,
> но к гибкости это отношения не имеет.

_Полному_ нубу намного легче нести пургу вроде вышеразобранной, увы.

Особенно насчёт "некуда".

Ответить | Правка | Наверх | Cообщить модератору

160. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от mikhailnov (ok), 02-Окт-20, 10:09 
В debian/rules часто достаточно прописать стандартную заглушку, и оно само решит, вызывать make, meson и пр., поэтому лично мне было проще осаоить сборку deb, но сейчас с rpm приятнее работать.
Ответить | Правка | Наверх | Cообщить модератору

159. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от mikhailnov (ok), 02-Окт-20, 10:05 
Как в debian/rules прописать путь к директории с корнем будущего пакета, почему его нужно угадать и почему он не вынесен в переменную окрудения (env)? В rpm это макрос %buildroot или эквивалентная переменная окружения RPM_BUILD_ROOT. Как прописать путь к стандартному расположению библиотек? Нужно вручную прописать /usr/lib/x86_64-linux-gnu и понадеяться, что не ошибся, да еще и для каждой архитектуры отдельный вариант сделать вручную, когда как в rpm просто макрос %_libdir. А задача упаковывать deb в обход dpkg-buildpackage весьма странная, попахивает корявой сборкой пакета, но иногда может быть полезно, согласен.
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

200. "Выпуск пакетного менеджера RPM 4.16"  –1 +/
Сообщение от Аноним (86), 03-Окт-20, 18:25 
Да что ж вы, только rpm видевшие, спорить про deb берётесь?
> Как в debian/rules прописать путь к директории с корнем будущего пакета, почему
> его нужно угадать и почему он не вынесен в переменную окрудения
> (env)? В rpm это макрос %buildroot или эквивалентная переменная окружения RPM_BUILD_ROOT.

Зачем тебе его явно прописывать? И в rpm-спеках так уже лет 10 никто не делает. А если нужно запаковать содержимое конкретного каталога, то для этого вообще никакой rules не нужен. dpkg-deb -b в руки и пакуй что хошь. Вот это называется гибкость, а не возможность переопределить макрос в спеке.

> Как прописать путь к стандартному расположению библиотек? Нужно вручную прописать /usr/lib/x86_64-linux-gnu
> и понадеяться, что не ошибся, да еще и для каждой архитектуры
> отдельный вариант сделать вручную, когда как в rpm просто макрос %_libdir.
> А задача упаковывать deb в обход dpkg-buildpackage весьма странная, попахивает корявой
> сборкой пакета, но иногда может быть полезно, согласен.

Вручную писать? Серьёзно?
На, любуйся. Надеюсь, с синтаксисом GNU make знаком хоть немножко? Не только %define в спеках умеешь?


$ cat /usr/share/dpkg/architecture.mk
# This Makefile snippet defines all the DEB_HOST_* / DEB_BUILD_* variables
# that dpkg-architecture can return. Existing values of those variables
# are preserved as per policy.

dpkg_lazy_eval ?= $$(or $$(value DPKG_CACHE_$(1)),$$(eval DPKG_CACHE_$(1) := $$(shell $(2)))$$(value DPKG_CACHE_$(1)))

dpkg_architecture_setvar = export $(1) ?= $(call dpkg_lazy_eval,$(1),dpkg-architecture -q$(1))

$(foreach machine,BUILD HOST TARGET,\
  $(foreach var,ARCH ARCH_ABI ARCH_LIBC ARCH_OS ARCH_CPU ARCH_BITS ARCH_ENDIAN GNU_CPU GNU_SYSTEM GNU_TYPE MULTIARCH,\
    $(eval $(call dpkg_architecture_setvar,DEB_$(machine)_$(var)))))


Ответить | Правка | Наверх | Cообщить модератору

203. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от mikhailnov (ok), 03-Окт-20, 21:39 
Спасибо за столь развернутое доказательство моей правоты. Билдрут много где в спеках пишут, создать папку и положить в нее файл - типовая операция.
Ответить | Правка | Наверх | Cообщить модератору

204. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от Аноним (86), 03-Окт-20, 23:14 
Тьфу блин, тебе не переопределить, а получить? Так не надо ничего гадать, имя каталога совпадает с именем пакета. Только никто ни папки, ни мамки в rules не создаёт, для этого есть debian/<package>.install
Ответить | Правка | Наверх | Cообщить модератору

215. "Выпуск пакетного менеджера RPM 4.16"  +1 +/
Сообщение от Michael Shigorinemail (ok), 05-Окт-20, 23:01 
> Спасибо за столь развернутое доказательство моей правоты.

Хозяйке на заметку: с того же питерского IP, с которого пришло #200, в соседней теме про Эльбрус Линукс так же глупо пытаются вещать про "расследования".

А потом они искренне удивляются -- "а нас-то за шо"...

За всё и сразу.

Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

168. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от n00by (ok), 02-Окт-20, 12:59 
> А вот в rpm гибкости нет. Кроме rpmbuild ничем пакет не сделать.

emerge может собирать rpm пакеты.

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

174. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от Аноним (86), 02-Окт-20, 17:08 
Про emerge не знал. Но что он там, внутри себя, не дёргает всё тот же rpmbuild — не верю. А дёргать rpmbuild много кто умеет: cpack, fpm… Предварительно сформировав для него спек, само собой, иначе ведь он не работает.
Ответить | Правка | Наверх | Cообщить модератору

175. "Выпуск пакетного менеджера RPM 4.16"  –1 +/
Сообщение от n00by (ok), 02-Окт-20, 18:21 
rpm это всего лишь формат пакетов, альтернативой ему является tar. В зависимостях portage нет rpm. Лень смотреть, чем именно ebuild упаковывает в rpm файлы, собранные по *.ebuild. https://www.mankier.com/1/ebuild#Commands-rpm но rpmbuild там точно не используется -- он же не понимает *.ebuild.
Ответить | Правка | Наверх | Cообщить модератору

185. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от Аноним (86), 02-Окт-20, 22:24 
Ну да, ну да…
https://github.com/gentoo/portage/blob/0bd5b693ef12c266000aa...
Ответить | Правка | Наверх | Cообщить модератору

194. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от n00by (ok), 03-Окт-20, 07:03 
Ещё раз. Portage собирает RPM пакеты по спецификациям из файлов с расширением EBUILD. Такими буквами видно?

Или Вам не ясна разница между исходным заявлением "Кроме rpmbuild ничем пакет не сделать" и "собрать пакет по .spec-у"?

Ответить | Правка | Наверх | Cообщить модератору

198. "Выпуск пакетного менеджера RPM 4.16"  –1 +/
Сообщение от Аноним (86), 03-Окт-20, 17:52 
Не надо мне ничего повторять ещё раз. Я уже написал, как это происходит: portage формирует спек и запускает rpmbuild. Если со зрением плохо, то вот создание спека: https://github.com/gentoo/portage/blob/0bd5b693ef12c266000aa...
А теперь сравни с deb. Там приблизительный аналог rpmbuild — dpkg-buildbpackage. Но можно обойтись и без него, запаковав содержимое каталога с файлами для установки и каталога с файлами метаданных с помощью dpkg-deb -b (никаких аналогов спека ему не надо, просто два каталога, и всё). А можно обойтись и без dpkg-deb, запаковав то же самое стандартными tar и ar, вообще на любой unix-образной системе, без необходимости устанавливать dpkg.
Ответить | Правка | Наверх | Cообщить модератору

199. "Выпуск пакетного менеджера RPM 4.16"  –1 +/
Сообщение от Michael Shigorinemail (ok), 03-Окт-20, 18:02 
> А теперь сравни с deb.

m4/dpkg-progs.m4:# Specify GNU tar program name to use by dpkg-deb. On GNU systems this is
m4/dpkg-progs.m4:# usually simply tar, on BSD systems this is usually gnutar or gtar.
Вы до сих пор не понимаете, что звать предназначенные для работы с контейнером утилиты -- вообще-то так и задумано?

> А можно обойтись и без dpkg-deb, запаковав то же самое стандартными tar и ar,
> вообще на любой unix-образной системе, без необходимости устанавливать dpkg.

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

Так-то и rpm2cpio.sh на всякий под рукой есть, но если надо _собирать_ -- то всегда оказывался прямой смысл собрать сперва rpm (уж не знаю, доводилось ли Вам что-либо бутстрапить -- у меня это e2k-alt-linux как минимум).

Ответить | Правка | Наверх | Cообщить модератору

205. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от n00by (ok), 04-Окт-20, 09:21 
> Не надо мне ничего повторять ещё раз.

В смысле, я разговариваю со стеной? Ничего подобного, я пишу читателям, кого может исходное "Кроме rpmbuild ничем пакет не сделать" ввести в заблуждение.

> Я уже написал, как это
> происходит: portage формирует спек и запускает rpmbuild.

Да пусть оно ещё хоть при помощи kdetoys экспедицию NASA на Луну запускает -- это не отменяет ортогонального.

Основная функция Portage -- сборка компонентов системы по сценариям из файлов ebuild.
После чего файлы, как правило, устанавливаются непосредственно в систему.
Однако, есть вариант упаковать файло в бинарные пакеты (например, что бы установить их в другую систему). Пакеты могут быть как в формате tar, так и в rpm.

> Если со зрением плохо,
> то вот создание спека: https://github.com/gentoo/portage/blob/0bd5b693ef12c266000aa...

Прекрасно видна попытка подменить исходный тезис на "выполнить сценарий spec-файла"

> А теперь сравни с deb. Там приблизительный аналог rpmbuild — dpkg-buildbpackage.
> Но можно обойтись и без него, запаковав содержимое каталога с файлами
> для установки и каталога с файлами метаданных с помощью dpkg-deb -b
> (никаких аналогов спека ему не надо, просто два каталога, и всё).
> А можно обойтись и без dpkg-deb, запаковав то же самое стандартными
> tar и ar, вообще на любой unix-образной системе, без необходимости устанавливать
> dpkg.

А потом до кучи запустить alien -- и внезапно получить пакет rpm, не имея к нему spec-файла.

Ответить | Правка | Наверх | Cообщить модератору

207. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от Аноним (86), 04-Окт-20, 11:22 
> я пишу читателям, кого может исходное "Кроме rpmbuild ничем пакет не сделать" ввести в заблуждение.

Ты пишешь:
> rpm это всего лишь формат пакетов, альтернативой ему является tar.

Тем самым вводя читателей в заблуждение. tar — формат архивов, а не пакетов.
Ты пишешь:
> В зависимостях portage нет rpm
> rpmbuild там точно не используется -- он же не понимает *.ebuild.

Это чушь собачья, что я и продемонстрировал выше.

И да, кроме rpmbuild rpm-пакет ничем не сделать. Любая обёртка будет вызывать rpmbuild. Никуда ты от этого не денешься. Ничем, кроме шестигранника, винт с шестигранным шлицем не закрутить, и даже если ты берёшь шуруповёрт, то всё равно вставляешь в него ту же шестигранную биту.

Ты так и не понял главного. rpm плох тем, что в нём нет нормального низкоуровневого инструмента для работы с пакетами. И вот это вот всё непотребство с созданием спека и вызовом rpmbuild в нутре portage, alien, cpack, fpm и прочего — костыли для обхода отсутствия такого инструмента. Это я пишу с точки зрения разработчика, копавшегося в коде подобных утилит, если что. Упаковка deb-пакета в них реализуется намного проще, чем rpm. Взять любую из них и подсчитать число строк кода, нужного для упаковки в тот и другой формат, предоставляю тебе.

Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

209. "Выпуск пакетного менеджера RPM 4.16"  –1 +/
Сообщение от n00by (ok), 04-Окт-20, 15:31 
>> я пишу читателям, кого может исходное "Кроме rpmbuild ничем пакет не сделать" ввести в заблуждение.
> Ты пишешь:
>> rpm это всего лишь формат пакетов, альтернативой ему является tar.
> Тем самым вводя читателей в заблуждение. tar — формат архивов, а не
> пакетов.

Вы забыли указать принципиальную меж ними разницу. Потому что в данном контексте её нет.

> Ты пишешь:
>> В зависимостях portage нет rpm
>> rpmbuild там точно не используется -- он же не понимает *.ebuild.
> Это чушь собачья, что я и продемонстрировал выше.

Вы там продемонстрировали, что для Вас rpm -- это готовый файлик, куда упакована уже собранная программа (в контексте Portage как раз аналог tar), а не сценарий её сборки с разрешением сборочных зависимости.

> И да, кроме rpmbuild rpm-пакет ничем не сделать.
> Это я пишу с точки зрения разработчика, копавшегося в коде подобных утилит, если что.

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

Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

212. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от Аноним (86), 04-Окт-20, 18:20 
> Вы забыли указать принципиальную меж ними разницу. Потому что в данном контексте её нет.

Разница в том, что пакет служит для установки софта в систему, а архив — для хранения произвольных файлов. Архив, в том числе tar, может являться пакетом, если содержит файлы для установки и метаданные для пакетного менеджера. В общем же случае — не является.

> Вы там продемонстрировали, что для Вас rpm -- это готовый файлик, куда упакована уже собранная программа (в контексте Portage как раз аналог tar), а не сценарий её сборки с разрешением сборочных зависимости.

Если говорить о пакете формата RPM, то да, любой пакет (не только rpm) — это готовый файлик, который существует совершенно независимо от сценария сборки. Потому что бывают нетиповые варианты создания пакетов, как в тех же portage или alien (это ведь не я их первым в качестве примера приводил, да?). Так вот, мы там что-то про гибкость тёрли, помнится. Под гибкостью обычно и подразумевают простоту адаптации к нетиповым сценариям использования. И, конечно, я именно о таких сценариях и пишу, чем демонстрирую, что помню контекст обсуждения.

> Вы это пишите как пользователь

Не буду.

Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

213. "Выпуск пакетного менеджера RPM 4.16"  +/
Сообщение от n00by (ok), 05-Окт-20, 09:51 
>> Вы забыли указать принципиальную меж ними разницу. Потому что в данном контексте её нет.
> Разница в том, что пакет служит для установки софта в систему, а
> архив — для хранения произвольных файлов. Архив, в том числе tar,
> может являться пакетом, если содержит файлы для установки и метаданные для
> пакетного менеджера. В общем же случае — не является.

У нас здесь частный случай, когда tar и rpm используются в одном сценарии.

>> Вы там продемонстрировали, что для Вас rpm -- это готовый файлик, куда упакована уже собранная программа (в контексте Portage как раз аналог tar), а не сценарий её сборки с разрешением сборочных зависимости.
> Если говорить о пакете формата RPM, то да, любой пакет (не только
> rpm) — это готовый файлик, который существует совершенно независимо от сценария
> сборки. Потому что бывают нетиповые варианты создания пакетов, как в тех
> же portage или alien (это ведь не я их первым в
> качестве примера приводил, да?).

Да, я привёл пример Portage. В темах про Альт не раз видел претензии к rpm, мол, отсутствует гибкость, нельзя (точнее, сложно -- требует правки spec) сконфигурировать пакеты при сборке. На самом деле существует возможность собрать пакет используя дерева portage и USE-флаги. Аналогично и с alien.

> Так вот, мы там что-то про гибкость
> тёрли, помнится. Под гибкостью обычно и подразумевают простоту адаптации к нетиповым
> сценариям использования. И, конечно, я именно о таких сценариях и пишу,
> чем демонстрирую, что помню контекст обсуждения.

Нетиповой сценарий использования микроскопа -- забивание гвоздей.

Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру