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

"Выпуск пакетного менеджера RPM 4.16"	+/–
Сообщение от opennews (ok), 30-Сен-20, 17:28
После года разработки состоялся релиз пакетного менеджера RPM 4.16.0. Проект RPM4 развивается компанией Red Hat и используется в таких дистрибутивах, как RHEL (включая производные проекты CentOS, Scientific Linux, AsiaLinux, Red Flag Linux, Oracle Linux), Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS, Tizen и многих других. Ранее независимой командой разработчиков развивался проект RPM5, который непосредственно не связан с RPM4 и в настоящее время заброшен (не обновлялся с 2010 года).  Код проекта распространяется под лицензиями GPLv2 и LGPLv2... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53811
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Выпуск пакетного менеджера RPM 4.16"	–15 +/–
Сообщение от Fracta1L (ok), 30-Сен-20, 17:28
Чем он лучше pacman на десктопе?
Ответить | Правка | Наверх | Cообщить модератору

	2. "Выпуск пакетного менеджера RPM 4.16"	+7 +/–
	Сообщение от Аноним (2), 30-Сен-20, 17:31
	Не лучше и не хуже, это другое.
	Ответить | Правка | Наверх | Cообщить модератору

	3. "Выпуск пакетного менеджера RPM 4.16"	–12 +/–
	Сообщение от Fracta1L (ok), 30-Сен-20, 17:37
	Жаль
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Выпуск пакетного менеджера RPM 4.16"	+2 +/–
	Сообщение от Аноним (4), 30-Сен-20, 17:49
	Пакман вроде очень примитивный по сравнению с рпм, был, во всяком случае.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	22. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
	Сообщение от лютый жабби__ (?), 30-Сен-20, 20:13
	>Пакман вроде очень примитивный по сравнению с рпм Зато научиться создавать пакеты для aur можно за 5 минут, а вот для rpm.....
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Выпуск пакетного менеджера RPM 4.16"	+8 +/–
	Сообщение от Чебур (?), 30-Сен-20, 21:12
	вероятно это одна из причин по которой AUR помойка
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (58), 01-Окт-20, 11:10
	это одна из причин почему человеков так много, их тоже легко делать
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Выпуск пакетного менеджера RPM 4.16"	+5 +/–
	Сообщение от Денис (??), 30-Сен-20, 21:35
	По слухам, все равно проще, чем для deb.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	30. "Выпуск пакетного менеджера RPM 4.16"	+2 +/–
	Сообщение от Nxx (ok), 30-Сен-20, 22:43
	Для rpm очень легко создавать пакеты. Ну, смотря какие пакеты, кончно, но, вообще, просто.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	82. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:11
	Да ладно, вот моя болванка "спека с нуля": Name: Version: Release: alt Summary: License: Group: Url: Source: %url/%name-%version.tar.gz #Patch: %name-%version-alt-makefile.patch Packager: Michael Shigorin <mike@altlinux.org> %description %prep %setup #%patch1 -p1 %build %configure %make_build %install %makeinstall_std %files %_bindir/* %doc AUTHORS ChangeLog FAQ NEWS README TODO # use add_changelog to add/grow %changelog section Ничего умного...
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	86. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (86), 01-Окт-20, 15:17
	Это только для допотопных версий rpm актуально. Сейчас макросы поудобнее в ходу.
	Ответить | Правка | Наверх | Cообщить модератору

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

	83. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (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 Shigorin (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 Shigorin (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 Shigorin (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ообщить модератору

	216. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 08-Окт-20, 18:52
	> Пакман вроде очень примитивный по сравнению с рпм В чем примитивность?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	13. "Выпуск пакетного менеджера RPM 4.16"	+2 +/–
	Сообщение от m.makhno (ok), 30-Сен-20, 18:49
	зачем, зачем Вы задаёте такие вопросы, мистер Андерсон?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	19. "Выпуск пакетного менеджера RPM 4.16"	+4 +/–
	Сообщение от Ilya Indigo (ok), 30-Сен-20, 19:24
	pacman нельзя сравнивать напрямую с rpm. pacman это что-то вроде связки rpm + (zypper, yum, dnf). zypper лучше тем, что в нём более понятный и интуитивный синтаксис, в отличие от packman, в котором его нужно просто тупо заучивать. А также в zypper можно делать абсолютно все пакетные операции через команды, без необходимости править конфиги, при том править конфиги тоже можно с тем же результатом.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	49. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Аноним (49), 01-Окт-20, 09:28
	Сильная (и одновременно слабая) сторона zypper в том, что в ситуации, когда зависимости пакета разрешить невозможно, или произошла какая-то другая непредвиденная  ситуация, он вместо того, чтобы сложить лапки к верху, как это делают другие пакетные менеджеры, предлагает пользователю проигнорировать условности и выстрелить себе в ногу.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 01-Окт-20, 10:01
	По zypper (d)up все откатится, все равно.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Выпуск пакетного менеджера RPM 4.16"	–5 +/–
	Сообщение от Ilya Indigo (ok), 01-Окт-20, 14:16
	> Сильная (и одновременно слабая) сторона zypper в том, что в ситуации, когда > зависимости пакета разрешить невозможно, или произошла какая-то другая непредвиденная >  ситуация, он вместо того, чтобы сложить лапки к верху, как > это делают другие пакетные менеджеры, предлагает пользователю проигнорировать условности > и выстрелить себе в ногу. Вы написали глупость! Он никогда не предлагает проигнорировать что-либо! В случае невозможности решить конфликт пакетов или файлов он предлагает пользователю варианты решений одно из которых и по умолчанию a (Abort)! Он по умолчанию предлагает r (Retry) только при невозможности получить файл по curl (пакет или методанные репы), и только несколько раз, а потом предлагает a (Abort).
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	62. "Выпуск пакетного менеджера RPM 4.16"	–4 +/–
	Сообщение от Аноним (58), 01-Окт-20, 12:25
	> zypper лучше тем, что в нём более понятный и интуитивный синтаксис, в отличие от packman, в котором его нужно просто тупо заучивать. "заучить" это громко сказано, просто нужно понять принцип и тогда всё очень легко воспринимается: pacman -S -- работа/синхронизация с удалённой базой(скачать(y), найти(s), показать(i) ...) pacman -F -- "продвинутый" поиск в удалённой базе(сама база скачивается(y) на комп) pacman -Q -- работа с локальной базой(найти(s), показать(i) ...) pacman -R -- работа с локальной базой(удаление) понимание этого хватит для 98% случаев, остальное довольно легко ищется(-Sh, -Fh, -Qh ...) даже если глянуть ту же Rosetta в арчвики https://wiki.archlinux.org/index.php/Pacman/Rosetta то видно что если брать в целом, а не судить по отдельным командам, то синтаксис pacman-а выглядит более лаконичным и понятным
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	77. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Ilya Indigo (ok), 01-Окт-20, 14:04
	sudo zypper 1 1: dup, up, in, rm, se, wp (Dist Update, Update, Install, Remove, Serch, What Provides) examples: sudo zypper dup, sudo zypper up [-rRepoName] [PackName], sudo zypper in [-rRepoName] PackName, sudo zypper rm PackName, zypper se PackName, zypper wp ExecOrLibName sudo zypper 12 ... 1: {a,r,m,l} (Add, Remove, Modify, List) 2: {r,l} (Repo, Lock) examples: sudo zypper rr (Remove Repo), sudo zypper ll (List Lock). sudo zypper al (Add Lock) Чувствуете разницу на сколько всё просто и интуитивно понятно? Не нужно даже знать используется синхронизация с базой или прочие изложенного Вами в pacman, просто коротко пишешь что хочешь чтобы zypper сделал, практически дословно, и он это делает! P.S. Даже если год не используешь zypper, а потом нужно что-то сделать с ним, то мгновенно вспоминаешь команды, потому что они, буквально, дословны и очевидны.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (58), 01-Окт-20, 16:10
	> examples: sudo zypper dup, sudo zypper up [-rRepoName] [PackName], sudo zypper in [-rRepoName] PackName, sudo zypper rm PackName, zypper se PackName, zypper wp ExecOrLibName давайте просто покажу на примере вместо: zypper dup zypper up ... zypper in ... можно заменить на один: pacman -Syu пакет(ы) читается как - скачать(y) удалённую(S) базу и обновить(u) систему, а также установить пакеты если таковые указаны. при желании можно разложить на составляющие скачать и установить пакет(ы) pacman -S пакет(ы) просто скачать новую базу с сервера pacman -Sy обновить систему pacman -Su скачать базу и по ней обновить систему pacman -Syu
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Ilya Indigo (ok), 01-Окт-20, 18:08
	> pacman -S -- работа/синхронизация с удалённой базой(скачать(y), найти(s), показать(i) ...) S - у людей ассоциируется с Set, Search, Slave, Sync. Это нужно заучить, и повторять перед сном, что S в pacman это Sync with remote base, и что вообще в pacman зачем-то предполагает, по умолчанию, работу только с локальной базой. а для нормальной работы нужно всегда этот флаг указывать. > скачать(y), показать(i) install или download это "y"... тут одного повторения перед сном явно не достаточно... тут, как минимум. страницу в тетреди исписать нужно. что y в pacman это install... > pacman -F -- "продвинутый" поиск в удалённой базе(сама база скачивается(y) на комп) Как раз флаг S (Search) больше ассоциируется с поиском, чем F. > pacman -Q -- работа с локальной базой(найти(s), показать(i) ...) Q - Local Base... снова в тететрадку и минимум 2 страницы... > скачать и установить пакет(ы) > pacman -S пакет(ы) > просто скачать новую базу с сервера > pacman -Sy > обновить систему > pacman -Su > скачать базу и по ней обновить систему > pacman -Syu Зачем вообще по отдельности скачивать и устанавливать? На ум приходит только если, по какай-то причине, обновляться вы не хотите (Видимо на арчике каждое обновление это лотерея), но поиск хотите выполнить по актуальной базе. Очень редкий случай. sudo zypper ref (Refresh) опять-таки очевидный синтаксис. Но в арчике это сделано по умолчанию что кому-то придёт в голову просто скачать пакеты не обновляясь или обновится с необновлённой базы... И как следствие нужно вместо -U или -up заучивать -Syu, подразумевая что pacman сам не догадается обновить базу перед обновлением системы. Просто великолепный как синтаксис, так и принцип работы... И вы говорите что он понятный и его не нужно заучивать?
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (58), 01-Окт-20, 20:25
	> S - у людей ассоциируется с Set, Search, Slave, Sync.... ну да всё логично -S --sync , а по поводу ассоциации у людей(?) с dup о котором я написал постом ниже. по поводу трудно запомнить, ну я не знаю, это надо обладать памятью бабочки чтобы с этим не справится > вообще в pacman зачем-то предполагает, по умолчанию, работу только с локальной базой. это где вы такого набрались ? > а для нормальной работы нужно всегда этот флаг указывать. конечно нужно, команды в пакман похожи на конструктор pacman -Si пакет pacman -Qi пакет выведет информацию(i) по пакету с удалённой(S)/локальной(Q) базы для зипер как я понял это zypper info/if пакет ассоциация с if еще похлеще чем с dum, хотя наверное находятся любители и такого я так и не понял info выведет информацию по локально установленному пакету или подтянет инфо с удалённой базы ? непонятно > install или download это "y"... тут одного повторения перед сном явно не достаточно... тут, как минимум. страницу в тетреди исписать нужно. что y в pacman это install... тут да -y, --refresh ключ -r был занят более глобальным(-r, --root <путь> указать альтернативный корневой каталог) поэтому выбрали другой, хотя если вы хоть раз ставили Arch это первое что запоминается и больше проблем не возникает, так что страницу в тетради а то и две можете потратить на zypper if которая используется для вывода информации по пакету из примера выше. >> pacman -F -- "продвинутый" поиск в удалённой базе(сама база скачивается(y) на комп) > Как раз флаг S (Search) больше ассоциируется с поиском, чем F. вообще то -F --files довольно точно отражает суть ключа если больше разбираться в ситуации, при -Fy скачивается не просто удалённая база как при -Sy а + дополнительная информация по всем ФАЙЛАМ принадлежащих пакетам, поэтому зная например имя утилиты(или какого либо файла) легко найти пакет которому он принадлежит и наоборот, раньше для этого была отдельная утилита но несколько версий назад решили включить в pacman. Почему не включили в тот же -S ? во первых, более полная база более тяжелая, например одна из оф.репа extra в сжатом виде весит 1656,0 KiB , а более полная уже 9,1 MiB да и нагружать сервера по поиску не тока зависимостей пакетов но и принадлежности файлов - в пакетах никто не будет, поэтому если нужно то скачивайте отдельно и ищите. В общем это специфическая вещь, но как видно всё организованно довольно логично. >> pacman -Q -- работа с локальной базой(найти(s), показать(i) ...) > Q - Local Base... снова в тететрадку и минимум 2 страницы... -Q --query - всё логично, ключ для запросов к локальной базе установленных пакетов только смотрите пальцы в кровь не сотрите, как там в пословице(немного перефразировал под ситуацию): "За дурною головою и пальцам горе" > Зачем вообще по отдельности скачивать и устанавливать? я просто привел пример что команды pacman как конструктор их можно легко разложить/сложить на составляющие и это будет легко читаться > На ум приходит только если, по какай-то причине, обновляться вы не хотите (Видимо на арчике каждое обновление это лотерея), > но поиск хотите выполнить по актуальной базе. Очень редкий случай. редкий или не редкий, вопрос в другом, что нужную мне команду можно довольно легко сформировать из кирпичиков при этом понимая что получу на выходе, а не путаясь в разных сокращения придуманных на все или не все случаи жизни. > sudo zypper ref (Refresh) опять-таки очевидный синтаксис. Но в арчике это сделано по умолчанию что кому-то придёт в голову просто скачать пакеты не обновляясь или обновится с необновлённой базы... И как следствие нужно вместо -U или -up заучивать -Syu, подразумевая что pacman сам не догадается обновить базу перед обновлением системы. вы не понимаете что такое гибкий инструмент, возможно вам нужно было родится китайцем у которых иероглифы на все случаи жизни, и свою тетрадку использовали бы по назначению. > И вы говорите что он понятный и его не нужно заучивать? зачем вы заучиваете весь синтаксис пакетных менеджеров я не знаю, сам же я знаю всего с десяток ключей которые притом не заучивались а естественным образом за несколько использованний воспринимались а потом легко воспроизводились, это как азбука, если понял азы то можешь писать и читать любые книги без проблем.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (58), 01-Окт-20, 20:43
	не дописал, исправляю >  во первых, более полная база более тяжелая, например одна из оф.репа extra в сжатом виде весит 1656,0 KiB , а более полная уже 9,1 MiB во первых, полная база более тяжелая, например сейчас одна из оф.репа extra в сжатом виде весит 1656,0 KiB , а более полная уже 9,1 MiB, поэтому с ней работают локально а не на удаленном сервере во вторых, -S подразумевает всё же работу с удалённой(находящейся на сервере) информацией. И хоть она и скачана но ключ -Q также не подойдёт так как -Q это обращение к локальной базе установленных пакетов, а мы скачали полную с доп инфой по файлам поэтому и выбрали -F как отдельная ветвь работы с полной базой локально.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (86), 02-Окт-20, 15:51
	> можно заменить на один: > pacman -Syu пакет(ы) Это не мнемонично. Мнемонично так: pacman -Suy пакет(ы)
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	193. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 03-Окт-20, 01:38
	Да какая разница. Ведь можно алиасы любые задать.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:17
	> -S > -F > -Q > -R > синтаксис pacman-а выглядит более лаконичным и понятным Лишний shift мне лично лаконичным не кажется.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	101. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Аноним (58), 01-Окт-20, 16:13
	сделай себе голосовой ввод и проблема шифта отпадёт
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 01:11
	> сделай себе голосовой ввод и проблема шифта отпадёт Ага, голосовой ввод в рутшелл.  Там не только эта проблема отпадёт на первом же dd.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Аноним (58), 02-Окт-20, 02:02
	просто дикцию подтяни и сможешь быть с компьютером на ты
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 16:32
	Мальчик, я был с компьютером "на ты" ещё при Союзе :-)
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (58), 02-Окт-20, 22:36
	постой, это случайно не про тебя тогда писали в газете "Правда" о том что ты мысленно мог общаться с компьютером ЭВМ "МИР-2" ?
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 03-Окт-20, 01:36
	> Мальчик, я был с компьютером "на ты" ещё при Союзе Это получается лет в 10-13, так?
	Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

	196. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от n00by (ok), 03-Окт-20, 08:07
	Железо того времени устроено существенно проще. Можно было разложить по полочкам в голове принципиальную схему клона Спектрума, или программировать в машинных кодах (без мнемоник) БК-0010. С тех пор сложность растёт, как и порог вхождения, только особо одарённые могут сейчас сходу на диалекте баш разрабатывать ОС.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 03-Окт-20, 12:49
	>> я был с компьютером "на ты" ещё при Союзе > Это получается лет в 10-13, так? Ага.
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	202. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 03-Окт-20, 19:07
	А интернет когда появился? Там ведь был сначала фидонет. У меня в 2005 в виде диалапа, вместе с компом. Мне было 20. До этого увлекался только звукозаписью.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Ilya Indigo (ok), 01-Окт-20, 17:41
	>> -S >> -F >> -Q >> -R >> синтаксис pacman-а выглядит более лаконичным и понятным > Лишний shift мне лично лаконичным не кажется. А Вас не смущает что половина этих букв никак не ассоциируется с действием, которая она выполняет, а другая половина ассоциируется не верно?
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	114. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (58), 01-Окт-20, 18:16
	> А Вас не смущает что ни одна из этих букв никак не ассоциируется с действием, которая она выполняет? ни одна ? странно, ведь, например, тот же ключ -R --remove очень красноречиво говорит о применении, или возможно у вас сформированы совершенно иные(инклюзивные) ассоциативные связи, в наш непростой век это нормально, для меня например совершенно непонятно почему использовали 'zypper dup' единственное что приходит на ум это dup(duplicate?) как дубликат хотя не совсем понятно что и кто дублируется. По описанию с того же сайта суси https://ru.opensuse.org/SDB:Zypper_использование_11.3 где написанно "По команде “zypper dup” будет предпринята попытка синхронизировать уже установленные пакеты с пакетами, которые можно получить из (всех) репозиториев, которые вы включили." на фоне этого ключ пакмана -S --sync выглядит на порядок понятным и логичным.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Ilya Indigo (ok), 01-Окт-20, 18:44
	Да, ни одна. -R ассоциируется с recursive (chmod/chown/chgrp). rm асcоциируется однозначно с удалением. -F поиск это search а не find, с F ассоциируется Force. dup это сокращение от dist-upgrade, можно написать и sudo zypper dist-upgrade, просто я люблю использовать краткий синтаксис. Отличие от обычного обновления (up), происходит смена поставщиков пакетов (репозиториев) если в других репозиториях пакеты свежее или они удалены (происходит даунгрейд или удаление если нет альернатив). Это необходимо при мажорном обновлении с одной версии на другую или для полного но опасного обновления Tumbleweed. При up такого не происходит это безопасное обновление. но может обновить не всё. > на фоне этого ключ пакмана -S --sync выглядит на порядок понятным и логичным Не логично выглядит зачем этот ключ нужно указывать и почему он не указывается сам при -y и почему также вместе с ним не указывается -u.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (58), 01-Окт-20, 21:09
	> dup это сокращение от dist-upgrade, можно написать и sudo zypper dist-upgrade, просто я люблю использовать краткий синтаксис. -R --remove первая буква со слова remove, для меня ассоциация очевидна, хотя и с recursive тоже нормально, но раз прописав команду уже больше не запутаешься, а вот с dup ... теперь я понимаю почему у вас такие плотные ассоциации с тетрадкой, сочувствую >> на фоне этого ключ пакмана -S --sync выглядит на порядок понятным и логичным > Не логично выглядит зачем этот ключ нужно указывать и почему он не указывается сам при -y и почему также вместе с ним не указывается -u. давайте еще раз попробую объяснить, а то вижу вам трудно ключ -y есть, например, и у -F и он означает примерно то же самое - скачать базу, но только здесь она уже полная, то есть если указать просто ключ -y система(пакман) не поймёт какую базу качать. Поэтому в пакман выделены главные(направляющие) ключи которые пишутся с большой буквы и они в команде взаимоисключают друг друга.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Ilya Indigo (ok), 01-Окт-20, 21:46
	Да понял теперь как pacman устроен. В zypper есть только полная база (хотя список файлов НЕ установленных пакетов она не показывает, только зависимости и что предоставляет) и она одна и таже и для поиска и для установки/обновления, по этому тут такого геморроя нет. Скачать лишние 10МБ, даже пусть 50МБ не проблема, особенно если в самом обновлении качаться будет гораздо больше, но это даёт возможность упростить работу с ПМ автоматически обновляя базу при обновлении/установке. Мне такой подход нравится гораздо больше.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (58), 01-Окт-20, 22:44
	размер "полного" репозитория примерно в 5-10 раз больше по объёму от основного, в зависимости от количества пакетов. То есть в в зависимости от количества подключенных реп нагрузка на сеть/диск/процессор(распаковка) может значительно вырасти я например использую по минимуму подключенные сторонние репы - 3 офрепы(core,extra,community) и одну левую seblu, выходит порядка 6MiB если качать полные то где-то 42MiB. Здесь не проблема скачать базу, проблема в активном обновлении базы, если в репе обновляется хоть один пакет то нужно скачивать всю репу, то есть из трех оф.реп я не помню чтобы они в течении часа не обновились, на деле же это происходит намного чаще, конечно зависит от сервера с которого обновляешься и на сколько он часто запрашивает информацию про обновления, но нормальные сервера делают это довольно часто https://www.archlinux.org/mirrors/status/#successful В общем такое разделение скорее всего обусловлено издержками дистрибутивов построенных на модели ролинг-релиз, особенно Арча который под это заточен.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Ilya Indigo (ok), 01-Окт-20, 23:13
	В openSUSE Tumbleweed (тоже ролинг) основная репа Oss физически не может обновляться чаще чем раз в сутки, а если снапшот Factory не проходит QA, то он и вовсе пропускается и не попадает в Tumbleweed. Раз в день, а то и реже, выполнить sudo zypper dup и подождать вместо 10 секунд, 30 секунд, но при этом получить полную базу для поиска, для меня не проблема. По умолчанию в openSUSE ставится хрень которая обновляет автоматически, но я осознанно её нафиг сношу, обновляя только вручную и только когда мне это нужно и я готов к этому.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (58), 02-Окт-20, 01:55
	в openSUSE ролинг это всё же не основной способ распространения, отдельная ветка, нагрузка на сами сервера со стороны пользователей незначительная. я например у себя также раз в день обновляю(yay -Syu) систему, ручками, люблю "контроль на пальцах", а всяких автоматических приблуд в Арче если сам не установишь не появится. Но пользователи бывают разные, кому-то например нравится выводить каждую минуту(или несколько) инфу на коньки по новым пакетам или просто отслеживать инфу по появлению конкретного пакета, например, ядра чтобы только тогда делать обновления, вот тогда уже начинает иметь значение размер реп ибо гонять(качать, распаковывать) каждую минуту несколько мегабайт это всё же намного лучше чем несколько десятков мегабайт. то есть, уже просто обычный мониторинг может серьёзно напрячь ресурсы пользователя не говоря уже о сервере который не резиновый.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 02-Окт-20, 11:34
	> В openSUSE Tumbleweed (тоже ролинг) основная репа Oss физически не может обновляться чаще чем раз в сутки DVD openSUSE Tumbleweed вообще нереально скачать. Ссылка протухает за несколько часов, а торрентов нет. Раньше были (неофициально, если .torrent дописать), но прикрыли. Да и какой в них смысл, если там http зеркала напиханы, а торрент сидов нет. Через сервис offcloud.com если только, но он уже на ладан дышит.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	165. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 02-Окт-20, 11:37
	> offcloud.com Кстати, их сервер выкачивает 4.2 Гб за 1-2 минуты. Это 300-600 мбит/с получается.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Ilya Indigo (ok), 02-Окт-20, 11:57
	Иногда такое бывает, когда они кривое зеркало подсовывают с которого очень низкая скорость загрузки. Не понимаю. зачем вообще качать DVD? Я всегда качаю сетевой установщик и закатываю его на флешку через dd когда нужно установить.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
	Сообщение от Денис (??), 30-Сен-20, 21:34
	В rpm файловые зависимости.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	73. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Денис (??), 01-Окт-20, 13:36
	Из-за этого их очень трудно читать. В pacman'е тоже, я смотрю https://www.archlinux.org/packages/community/x86_64/audacity Кстати, что-то Arch слоупочит Flagged out-of-date on 2020-06-27 Last Updated: 2020-05-27 21:48 UTC В openSUSE Tumbleweed уже обновили. Так что даже Arch не гарант свежести.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
	Сообщение от Денис (??), 01-Окт-20, 13:38
	Некоторые прогрессивные вообще на Ubuntu LTS сидят. А древность "освежают" снапом.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:18
	> В rpm файловые зависимости. Они более-менее в любом развесистом управителе авосек -- в dpkg тоже были, насколько помню.  Кто-то их притом считает вредными.  Возможно, готовить не умеют...
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	92. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Аноним (86), 01-Окт-20, 15:21
	> в dpkg тоже были, насколько помню Попей таблеточки, может, память улучшится. Нет и не было.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 01:17
	>> в dpkg тоже были, насколько помню > Нет и не было. Действительно, если верить http://uneex.ru/static/PackageFormatComparison/index.html#it... > Попей таблеточки, может, память улучшится. PS: если я буду с _Вами_, юноша, дискутировать выписыванием таблеточек за хамство (п. 4 правил форума, см. ссылку вот под этой же формой) -- то полезное, что пытаетесь донести, получится прочесть только в логе модерирования.  Пожалуйста, берегите себя и свои тексты -- тогда для других они будут полезней. PPS: ну вот, при желании перепишите #146 как положено.
	Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск пакетного менеджера RPM 4.16"	+/–
Сообщение от Анонымоус (?), 30-Сен-20, 17:55
Кто-нибудь в курсе? Есть возможность проверить целостность файлов, установленных из пакета: rpm -V пакет или rpm -Va Проверяется, в частности, соответствие хэшей md5, сохраненных со времен установки пакета, тем, которые вычисляются по файлам при проверке. Проверить хэши можно. А извлечь?
Ответить | Правка | Наверх | Cообщить модератору

	7. "Выпуск пакетного менеджера RPM 4.16"	+6 +/–
	Сообщение от Аноним (7), 30-Сен-20, 18:09
	Для каждого файла в пакете binutils показывает хэш:     rpm -q --queryformat "[%{FILENAMES}\t%{FILEMD5S}\n]" binutils Конкретно в федоре вместо MD5 по факту показывает SHA256.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Анонымоус (?), 30-Сен-20, 20:31
	Спасибо, выручили.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Анонымоус (?), 01-Окт-20, 08:35
	В RHEL6 тоже SHA256 обнаружилось вместо MD5.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	41. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от mikhailnov (ok), 01-Окт-20, 02:49
	rpm -q --dump
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	45. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Анонымоус (?), 01-Окт-20, 08:29
	И Вам спасибо.
	Ответить | Правка | Наверх | Cообщить модератору

6. "Выпуск пакетного менеджера RPM 4.16"	+4 +/–
Сообщение от Аноним (6), 30-Сен-20, 18:04
> ... в СУБД SQLite ... вместо бэкенда на основе BerkeleyDB Началась перестановка кроватей.
Ответить | Правка | Наверх | Cообщить модератору

	9. "Выпуск пакетного менеджера RPM 4.16"	+2 +/–
	Сообщение от RPMbuild (?), 30-Сен-20, 18:17
	Избавлениние от блокировок в базе.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:20
	> Избавлениние от блокировок в базе. Над Panu и компанией опытные разработчики порой посмеивались -- те усердно топчут _давно_ известные грабли, увы.  И порой игнорируют предупреждения уже теперь.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от YetAnotherOnanym (ok), 30-Сен-20, 23:33
	> Реализован новый бэкенд > Реализован новый экспериментальный бэкенд > Удалён экспериментальный бэкенд > Объявлен стабильным бэкенд Это такой творческий поиск методом научного тыка. Некогда думать, надо бэкенды реализовывать.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

8. "Выпуск пакетного менеджера RPM 4.16"	–4 +/–
Сообщение от RPMbuild (?), 30-Сен-20, 18:16
GUI для создания спек файлов не видно на горизонте?
Ответить | Правка | Наверх | Cообщить модератору

	10. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от microsoft (?), 30-Сен-20, 18:25
	Хорошоб чтоб vim и ко поддерживала нормально спек файлы, а ты сразу гуй.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (86), 01-Окт-20, 01:26
	Всё там нормально в vim, чего тебе не хватает?
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:20
	> Хорошоб чтоб vim и ко поддерживала нормально спек файлы, а ты сразу гуй. apt-get install vim-plugin-spec_alt-ftplugin
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	12. "Выпуск пакетного менеджера RPM 4.16"	+5 +/–
	Сообщение от Аноним (12), 30-Сен-20, 18:38
	Но зачем?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	18. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (18), 30-Сен-20, 19:06
	Для изучения основ, не читать же документацию бураттнам.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:21
	> GUI для создания спек файлов не видно на горизонте? apt-get install vim-X11
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

14. "Выпуск пакетного менеджера RPM 4.16"	–15 +/–
Сообщение от Аноним (14), 30-Сен-20, 18:51
Ничего отстойнее в этом мире нет. Разве что только еще deb.
Ответить | Правка | Наверх | Cообщить модератору

	16. "Выпуск пакетного менеджера RPM 4.16"	+3 +/–
	Сообщение от microsoft (?), 30-Сен-20, 18:57
	Но что круто ты нас недостойных не просвятиш.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (-), 01-Окт-20, 01:17
	setup.exe
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (18), 01-Окт-20, 01:27
	InnoSetup и NSIS лучшие.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от ksjdjfgklsjdklgfj (?), 01-Окт-20, 09:39
	не знаю про nsis и inno, но стандартный вендовый MSI делается тоже не вот так просто... там ещё надо доков покурить чтобы сделать что-то простое
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Анончик9999 (?), 01-Окт-20, 12:36
	NSIS-установщик без доков тоже трудно вручную нормальный создать.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Анончик9999 (?), 01-Окт-20, 12:32
	Расскажи, как ты с этими инструментами будешь устанавливать софт на Linux. Вообще-то, хотелось, чтобы простой и красивый стандартный установщик в Windows-стиле соществовал хотябы для популярных дистрибутивов (не flatpack, snap, appimage),чтобы было просто и красиво создавать проприоритарные пакеты как разработчику, так и устанавливать их пользователю.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	65. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Анончик9999 (?), 01-Окт-20, 12:42
	В Qt есть установщик под Linux, но он ограничивается только Qt-софтом (устанавливал софт на нем - PDFMaker, FoxitReader). Даже на PyQt, PySide такой установщик создать не получится.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:22
	> Вообще-то, хотелось, чтобы простой и красивый стандартный установщик > в Windows-стиле соществовал хотябы для популярных дистрибутивов .run изобретён в Loki Software точно больше полутора десятилетий назад.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	140. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 02-Окт-20, 01:23
	> установщик > устанавливать софт на Linux За такое расстреливать полагается.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	39. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (39), 01-Окт-20, 01:31
	Ну не нравиться человеку он и выражает собственное фу. Хотя я бы на самом деле посмоетовал какое-то глобальное голосование сделать что бы вместо того что бы свой голос сувать в каждый топик про нелюбимую технологию он один раз проголосовал против RPM и один раз за любимый формат. Мне вот тоже DEB крайне раздражает, но за последние 10 лет я как-то уже привык.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	104. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 16:35
	Вы почитайте что сами пишете то. Какое голосование ? Извилина одна на толпу и та отторгается через раз. Вся это либерда билиберда уже никого не интересует, хоть обголосуйтесь до поноса, всем пофиг. Единственное что в толпе идиотов может быть и вменяемый человек, которому свободное мнение может быть полезно для как минимум не ощущения себя ненормальным в толпе идиотов. Вот что я думаю по этому поводу.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Выпуск пакетного менеджера RPM 4.16"	+2 +/–
	Сообщение от Sgt. Gram (?), 01-Окт-20, 22:55
	> Мне вот тоже DEB крайне раздражает Что он тебе раздражает?
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	27. "Выпуск пакетного менеджера RPM 4.16"	+2 +/–
	Сообщение от Аноним (27), 30-Сен-20, 21:27
	Мне во фряхе pkg нравится, минималистичный, быстрый и ничего не сломает.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	34. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
	Сообщение от Аноним (-), 01-Окт-20, 01:20
	А вот это очень близко к истине. Всяко ближе чем весь этот рпм-деб шлак и помойка.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (39), 01-Окт-20, 01:32
	А PKG в чем архивирует в tar.gz просто?
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 16:39
	Нет, как рыпымэ и дэб обворачивает любовью и словом добрым, укладывает почитывая молитвы и раздувая благовония. Откуда вы такие только беретесь, тушите свет, они лезут на свет !
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от mikhailnov (ok), 01-Окт-20, 02:51
	И не умеющий банально следить, от какого so name зависимость, при смене версии библиотеки фряха запросто случайно перестает работать
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	53. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (86), 01-Окт-20, 11:01
	dpkg тоже за этим не следит, однако Debian работать не перестаёт. Как так? АААА, МАГИЯ!!! P.S. Собственно, не знаю ни одного пакетного менеджера кроме rpm, который бы таким занимался. Оверинженеринг как он есть.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от mikhailnov (ok), 01-Окт-20, 13:49
	> dpkg тоже за этим не следит, однако Debian работать не перестаёт. Как > так? АААА, МАГИЯ!!! Там, где не следят, но работать типа не перестает, например, в Arch Linux, это достигается за счет траты большого кол-ва людских ресурсов: если обновили ffmpeg, mpv может полежать пару часов не пересобранным, но его быстро пересоберут, большинство пользователей не заметит, зато будет пропагандировать быстрый pacman.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от n00by (ok), 01-Окт-20, 14:13
	> зато будет пропагандировать > быстрый pacman. Но ты ведь сам здесь и сейчас накидываешь на FreeBSD (и совершенно напрасно), в то время как _у_тебя_ systemd конфликтует при обновлении с systemd.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 01-Окт-20, 15:02
	> если обновили ffmpeg, mpv может полежать пару часов не пересобранным Речь, конечно, идет о мажорном обновлении. Потому что в пределах ветки либы совместимы. Я как-то собирал "голый" ffmpeg. В смысле, без всяких внешних компонентов. С его либами собрал mpv. Потом я набил руку и собрал жирнющий ffmpeg с чем только можно. Но mpv пересобирать не стал. Просто указал ему новые либы. И все работало. mpv стал играть AV1 (через libdav1d) чего раньше не умел, без всяких пересборок. Но с мажорным обновлением ffmpeg'а, например с 4 на 5, такое не прокатит.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	108. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от n00by (ok), 01-Окт-20, 17:09
	>> если обновили ffmpeg, mpv может полежать пару часов не пересобранным > Речь, конечно, идет о мажорном обновлении. Потому что в пределах ветки либы > совместимы. Увы и ах. Однажды, в одном дистрибутиве обновили kodi, а ffmpeg остался "совместимой версии". При этом у одного из пользователей в видосиках из папки XXL тётеньки вдруг запели мужскими голосами. Тот бедняга слушал такое неделю и в итоге пришёл к гениальному выводу -- некий злодей взломал ему комп, что бы наказать его за непристойное поведение. mikhailnov почему-то, тыкая пальчиком в чужие mpv, не вспоминает эту замечательную историю. Вероятно, потому что он к ней причастен и там работает. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 02-Окт-20, 01:26
	Вообще кейс знаменит за пределами рунета, не конкретно прям вот так, не знаю подробностей - а именно приколы с ffmpeg - т.к он линкуется с кучей библиотек. И вот этот самый кейс от пакетного менеджера вообще не зависит, очень плохой пример.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 01:29
	> И вот этот самый кейс от пакетного менеджера вообще не зависит, > очень плохой пример. А ввиду #138 -- наоборот, ffmpeg представляет хороший пример сложного случая.  И как минимум один пакетный менеджер на планете его хорошо решает.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (-), 02-Окт-20, 10:50
	> И как минимум один пакетный менеджер на планете его хорошо решает. Прямые руки решают, а не пакетный менеджер. От того что там будет blah.so.0.1.1 в другом пакете blah.so.0.2.1 ничего в пакетном мире не поменяется. Ах ну да, как это так, рпмушка будет одинакового названия. Сколько говорить - это проблемы пакетных менеджеров, созданные пакетными менеджерами и все вокруг их хотят решить с помощью пакетных менеджеров. Короче выкеньте это все на свалку и попробуйте юникс вей.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 21:34
	>> И как минимум один пакетный менеджер на планете его хорошо решает. > Прямые руки решают, а не пакетный менеджер. *sigh* Кому интересно -- читайте сюда: http://www.linuxlib.ru/Linux/idealsa.htm Затем сюда: http://ftp.altlinux.ru/pub/people/at/protva-2010.pdf > От того что там будет blah.so.0.1.1 в другом пакете blah.so.0.2.1 > ничего в пакетном мире не поменяется. Вы вообще ничего не поняли, на ссылки тоже лучше время не тратьте.  Там объёмней/сложней, чем я пытаюсь (видимо, неудачно) объяснить на пальцах. > Короче выкеньте это все на свалку и попробуйте юникс вей. Вот только вкалывать в поту вручную вместо автоматики -- это windows way.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (-), 02-Окт-20, 23:21
	Так говорят же русским языком - все это в пакетном менеджере не нужно. Еще марио оттуда запускать осталось.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от n00by (ok), 02-Окт-20, 14:28
	> Вообще кейс знаменит за пределами рунета, не конкретно прям вот так, не > знаю подробностей - а именно приколы с ffmpeg - т.к он > линкуется с кучей библиотек. Ну да, интерфейс и реализация -- две большие разницы. Не только в случае ffmpeg, где неконсистентность выходит боком относительно часто, а в общем случае. > И вот этот самый кейс от пакетного > менеджера вообще не зависит, очень плохой пример. Кто понимает причины "кейса", тот может как-то его решать, с пакетным менеджером, или без оного. Остальным остаётся разглагольствовать про "ABI" и шукать по багтрекерам.
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	132. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 00:48
	Либы с одинаковым so name не обязательно имеют совместимый ABI. В ALT есть механизм хеширования ABI и прописывания в зависимости пакета. В апстримном RPM максимум версионирование символов учтет, можно было бы написать генератор провайдов и зависимостей по ABI, но там нужен особый механизм сравнения хешей, не rpm vercmp, а каждый символ записывать в Provides и Requires слишком жирно (но можно попробовать на aarch64).
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	147. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (-), 02-Окт-20, 01:29
	еще мультилиб туда запихнуть чтоб вот сразу и все. не нужно это пакетному менеджеру, все что он должен делать - распаковать ссылки и скинуть лог - все, не должно быть больше ничего.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 10:14
	> еще мультилиб туда запихнуть чтоб вот сразу и все. не нужно это > пакетному менеджеру, все что он должен делать - распаковать ссылки и > скинуть лог - все, не должно быть больше ничего. Сторонники такого подхода пользуются pacman и пр. максимально простыми пакетными менеджерами. Мне же хочется, чтобы пакетный менедже помогал держать систему работоспособной.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (86), 01-Окт-20, 15:28
	> Там, где не следят, но работать типа не перестает, например, в Arch Linux, это достигается за счет траты большого кол-ва людских ресурсов: если обновили ffmpeg, mpv может полежать пару часов не пересобранным, но его быстро пересоберут, большинство пользователей не заметит, зато будет пропагандировать быстрый pacman. И снова: в Debian такого не происходит. Да блин, что за магия-то? На самом деле, вообще никакой связи с зависимостями от версий soшников. Решается всего лишь правильным именованием пакетов с либами. Вот в Fedora, например, на это забили болт, и никакой rpm им не помогает: до mass rebuild'а половина пакетов в rawhide неработоспособна.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	109. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от n00by (ok), 01-Окт-20, 17:23
	Не тратьте время на повторы. Вот Вам анекдот: Здравствуйте! Не могу установить системные обновления из-за конфликтующих пакетов. Следующие пакеты будут удалены для обновления остальных: systemd-230-8-rosa2016.1.i586 (чтобы установить systemd-230-8-rosa2016.1.i586) systemd-units-230-8-rosa2016.1.i586 (чтобы установить systemd-units-230-8-rosa2016.1.i586) https://forum.rosalinux.ru/viewtopic.php?f=40&t=8839&hilit=s... Догадайтесь с трёх раз, кто автор сей характерной ошибки. :)
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 00:28
	Через git blame авторов ошибки и исправлений поискал бы
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от n00by (ok), 02-Окт-20, 13:49
	Хочешь сказать, что это не смешно? Пользователи джва года мучаются, а ты тут умничаешь. Ну да, пользователям не смешно.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 18:53
	> Хочешь сказать, что это не смешно? Пользователи джва года мучаются, а ты > тут умничаешь. Ну да, пользователям не смешно. Уже довольно давно не мучаются
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от n00by (ok), 03-Окт-20, 07:12
	>> Хочешь сказать, что это не смешно? Пользователи джва года мучаются, а ты >> тут умничаешь. Ну да, пользователям не смешно. > Уже довольно давно не мучаются Бытие таково, что постоянно против твоих мрий. 1 окт Однако в последнее время если правильно помню начиная с 11-й "свежести" начались какие-то странности. устанавливаешь все работает до первого большого обновления. если обновился штатно перестает запускаться, если systemd законфликтовал, запускается и работает нормально но в лотке всегда висит значек о наличии обновлений с этим самым systemd. В какой момент он начинает конфликтовать пока не понимаю. https://vk.com/wall-33847957_317585 Примечательно, даже штатный УМВР-бот обломался.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 00:30
	Механизмы RPM функциональнее, универсальнее и проще дебиановского dh_shlibs
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	134. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (86), 02-Окт-20, 01:08
	Это как посмотреть. У каждого подхода свои плюсы и минусы. Но проще однозначно дебиановский: он не вводит дополнительных сущностей, а оперирует только зависимостями от пакетов, идентифицируемых по имени, и их версий. Это затрудняет перекладывание файлов из одного пакета в другой, но зато упрощает и ускоряет разрешение зависимостей.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (-), 02-Окт-20, 01:33
	> Это как посмотреть. У каждого подхода свои плюсы и минусы. Но проще > однозначно дебиановский: он не вводит дополнительных сущностей, а оперирует только зависимостями Это дебиановское что-ли ? Проще ? Это вот та какуля на какуле через какулю в структуре какуль - простая и понятная ? Да вы гоните
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (86), 02-Окт-20, 01:49
	Я не знаю, про какие ты там какули (анальная фиксация?), но мы тут вообще-то о зависимостях пакетов. Так вот, вот это: $ dpkg-query -Wf '${depends}\n' rpm libc6 (>= 2.17), libelf1 (>= 0.131), libpopt0 (>= 1.14), librpm8 (>= 4.14.2+dfsg1), librpmbuild8 (>= 4.14.0+dfsg1), librpmio8 (>= 4.14.0+dfsg1), librpmsign8 (>= 4.14.0+dfsg1), perl:any, rpm2cpio, debugedit (= 4.14.2.1+dfsg1-1), rpm-common (= 4.14.2.1+dfsg1-1) проще, чем вот это: $ rpm -q --requires rpm /bin/bash /bin/sh /usr/bin/db_stat config(rpm) = 4.14.2-9.el8 coreutils curl libacl.so.1()(64bit) libarchive.so.13()(64bit) libaudit.so.1()(64bit) libbz2.so.1()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libcap.so.2()(64bit) libcrypto.so.1.1()(64bit) libdb-5.3.so()(64bit) libdl.so.2()(64bit) libelf.so.1()(64bit) liblua-5.3.so()(64bit) liblzma.so.5()(64bit) libm.so.6()(64bit) libpopt.so.0()(64bit) libpopt.so.0(LIBPOPT_0)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) librpm.so.8()(64bit) librpmio.so.8()(64bit) libz.so.1()(64bit) popt(x86-64) >= 1.10.2.1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) А если вспомнить, что в rpm отдельно указываются зависимости для *каждого* скриптлета, то там картина ещё сильнее усложняется.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 21:21
	> Это вот та какуля на какуле через какулю в структуре какуль - > простая и понятная ? Да вы гоните Хозяйке на заметку: среди разработчиков и админов точно есть такие, которым удобней работать со структурой объектов, и такие, кому удобней воспринимать структурированный объект (но один). Применительно к этому вопросу -- я в http://altlinux.org/m-p делал структуру объектов, pilot@ в http://altlinux.org/etcnet делал структуру объектов; соответственно на нас ругались те, кому удобней в mcedit найти что-либо в одной простынке, и те, кому милей дебиановская сетевая конфигурация опять же одной простынёй. То есть как минимум стоит учитывать, что тут и впрямь есть развилка и разным людям ближе плюсы разных вариантов.  Ну и что привычки -- тоже штука страшная (например, монолитный spec-файл тому же мне давно привычен, хотя это как раз "простынный" подход, а не "впорубку с будкой"). PS re #154: покажите-ка зависимости "каждого скриптлета" -- если так назвали Requires(pre), то это _возможность_, а не обязанность (полезная для ранних пакетов в графе зависимостей).  Да, и в проиллюстрированном примере в дебиане умно оптимизировали зависимости, спрятав тот же coreutils за perl:any, или тупо врут (как вот про rpm2cpio)? PPS: м-да, этот дебианщик оказался всё-таки глупой малолеткой, которая в жизни со своей "аргументацией" (и неумением воспринимать иную) явно ещё не раз будет рисковать своим таблом :(
	Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

	206. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от n00by (ok), 04-Окт-20, 10:13
	> То есть как минимум стоит учитывать, что тут и впрямь есть развилка > и разным людям ближе плюсы разных вариантов. Это же курс школьной психологии, дихотомии Юнга (правда, на фоне верований в ученье Маркса "материя для всех и при любом раскладе первична", теорию в своё время скомпрометировали). Отсюда же и противостояние командной строки с граф.интерфейсом, и феномен популярности Delphi в России. Интересно, что как раз здесь (на Опеннет) большинство должно быть в состоянии самостоятельно прийти к выводу о "развилках", но наблюдается обратное.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 04-Окт-20, 13:22
	> Это же курс школьной психологии, дихотомии Юнга (правда, на фоне верований в Пока вы тут псевдофилософствуете, конкуренты подсаживают твоих близких на всякие неведомые помои, т.к помои твоего производства можно псевдопонять через призму непонятных философствований но не здравый смысл и здорые потребности.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от n00by (ok), 04-Окт-20, 15:40
	А я смотрю, кое-кто аж прям светится через эту свою призму. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 04-Окт-20, 17:38
	> А я смотрю, кое-кто аж прям светится через эту свою призму. ;) Нет, мне обидно за здравый смысл.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	214. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от n00by (ok), 05-Окт-20, 10:15
	Разве я где-то тут табличку "доктор" нарисовал? Идите и поплачьте в уголке о безвозвратной утрате.
	Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

	138. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 01:20
	> На самом деле, вообще никакой связи с зависимостями от версий soшников. > Решается всего лишь правильным именованием пакетов с либами. Да щазз, сколько апстримов с библиотеками dsohowto не читали... В альте изобрели set versions, исключив этот класс проблем (к слову о генераторах, ага).
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	70. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 13:18
	> И не умеющий банально следить, от какого so name зависимость, при смене > версии библиотеки фряха запросто случайно перестает работать   pkg info glib                                                                   glib-2.66.0_1,1 Name           : glib Version        : 2.66.0_1,1 ... Shared Libs required:     libpcre.so.1     libintl.so.8     libelf.so.1     libiconv.so.2     libffi.so.7 Shared Libs provided:     libgthread-2.0.so.0     libglib-2.0.so.0     libgobject-2.0.so.0     libgio-2.0.so.0     libgmodule-2.0.so.0 # pkg check -d opencv is missing a required shared library: libprotobuf.so.23 virtualbox-ose is missing a required shared library: libssl.so.9 > при смене версии библиотеки фряха запросто случайно перестает работать В перепончатых мечтах, разве что. База на то и база, что обновляется целиком и работает отдельно от всего остального.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	75. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от mikhailnov (ok), 01-Окт-20, 13:45
	Спасибо, забыл про это.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (-), 01-Окт-20, 15:29
	> Спасибо, забыл про это. Справедливости ради, точные версии все же нужно прописать в манифесте пакета: jq < +COMACT_MANIFEST "shlibs_required": [     "libintl.so.8",     "libpcre.so.1",     "libelf.so.1",     "libiconv.so.2",     "libffi.so.7"   ],   "shlibs_provided": [     "libgthread-2.0.so.0",     "libglib-2.0.so.0",     "libgobject-2.0.so.0",     "libgio-2.0.so.0",     "libgmodule-2.0.so.0"   ], ну и сломать можно, если например пакет залочен, а совпадающая зависимость есть еще и у незалоченого - зависимость обновится. -- man pkg-upgrade Where a package on    the work list supplies a shared    library, and that li-      brary has been updated, all packages requiring that shared    library    will      also be added to the work list as reinstallation jobs. --
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (86), 01-Окт-20, 19:48
	Не знал, что там так можно, но пользы вот от такого, как в примере, не вижу. Неизменная старшая цифра версии указывает на сохранение обратной совместимости, но не прямой. Соответственно, такая зависимость не помешает установить бинарь в систему с более старой версией библиотеки, нежели та, с которой он был собран, и есть вероятность, что работать он не сможет. А что там с версионированием символов, кстати? rpm и про него знает.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 20:41
	> Не знал, что там так можно, но пользы вот от такого, как > в примере, не вижу. Неизменная старшая цифра версии указывает на сохранение > обратной совместимости, но не прямой. Соответственно, такая зависимость не помешает установить бинарь в систему с более старой версией библиотеки, нежели та, с которой он был собран, и есть вероятность, что работать он не сможет. Для этого есть версии самих пакетов. "deps": { ... "glib": {       "origin": "devel/glib20",       "version": "2.56.3_5,1" ... "shlibs_required": [     "libxcb-render.so.0",     "libglib-2.0.so.0", более свежая сборка "glib": {       "origin": "devel/glib20",       "version": "2.66.0_1,1"     }, "shlibs_required": [     "libxcb-render.so.0",     "libglib-2.0.so.0" будет требовать обновить пакет glib до весии 2.66.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (86), 01-Окт-20, 23:00
	Так и зачем тогда эта информация о либах, если всё равно надо указывать зависимости от содержащих их пакетов? В rpm весь профит как раз в том, что пакеты не прописываются, а зависимости от либ генерятся автоматически. В deb, наоборот, указывается только зависимость от пакетов с либами (версии не ниже той, с которой была сборка, тоже автоматически). А тут получается избыточность, да ещё и автоматизации никакой, как я понял. Или таки я недопонял чего-то? Или ты что-то недорассказал?
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 02-Окт-20, 01:23
	> Так и зачем тогда эта информация о либах, если всё равно надо > указывать зависимости от содержащих их пакетов? В rpm весь профит как > раз в том, что пакеты не прописываются, а зависимости от либ генерятся автоматически. В deb, наоборот, указывается только зависимость от пакетов с либами (версии не ниже той, с которой была сборка, тоже автоматически). А тут получается избыточность, да ещё и автоматизации никакой, как я > понял. Или таки я недопонял чего-то? Или ты что-то недорассказал? Зависимости указываются в билдфайле порта/пакета: https://svnweb.freebsd.org/ports/head/devel/glib20/Makefile?... LIB_DEPENDS+=   libpcre.so:devel/pcre \                     libffi.so:devel/libffi USES+=          compiler:c11 gettext gnome iconv:wchar_t \                     localbase:ldflags meson perl5 pkgconfig python:3.5+ При желании, можно указать минимум и т.д.: p5-Spiffy>=0.26:devel/p5-Spiffy Вот это - все, что прописывается "ручками" (причем, я бы не сказал, что glib "удачный" пример, но раз с него начали). Содержимое MANIFEST файла, с которым работает pkg (как и сам пакет) генерируется автоматически. -- ¹USES - предоставляемая инфраструктурой портов набор упрощающих обвязок, тот же /usr/ports/Mk/Uses/iconv.mk внутри содержит например .if ${iconv_ARGS:Mbuild} BUILD_DEPENDS+= ${ICONV_CMD}:converters/libiconv .elif ${iconv_ARGS:Mpatch} PATCH_DEPENDS+= ${ICONV_CMD}:converters/libiconv .else LIB_DEPENDS+=   libiconv.so:converters/libiconv .endif
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (86), 02-Окт-20, 01:36
	> Вот это - все, что прописывается "ручками" (причем, я бы не сказал, что glib "удачный" пример, но раз с него начали). > Содержимое MANIFEST файла, с которым работает pkg (как и сам пакет) генерируется автоматически. А, так уже понятнее, спасибо. Хотя по-прежнему не до конца ясен смысл избыточности зависимостей при недостатке их версионности…
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 02-Окт-20, 01:39
	> Зависимости указываются в билдфайле порта/пакета: они про другое, про версию либы и мультиверсионность , зоопарк корочее. сразу видно что вот во фре этого бардака нет, а тут на лицо удобный тулзы для выгребания навоза.
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	129. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 00:31
	Версии вручную надо прописать?
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	149. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от анонн. (?), 02-Окт-20, 01:31
	> Версии вручную надо прописать? Нет конечно. Но емнип, просто "по быстрому" указав список пакетов в зависимостях RUN_DEPENDS, списка shared lib c версиями в манифесте не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 10:13
	>> Версии вручную надо прописать? > Нет конечно. Но емнип, просто "по быстрому" указав список пакетов в зависимостях > RUN_DEPENDS, списка shared lib c версиями в манифесте не будет. А зачем runtime зависимости от библиотек прописывать вручную? В чем проблема сосьавить его автоматически?
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 02-Окт-20, 13:42
	> А зачем runtime зависимости от библиотек прописывать вручную? В чем проблема сосьавить его автоматически? Eсли что-то есть в RUN_DEPENDS, то совершенно не обязательно используются именно (все) библиотеки оттуда. А насчет автомагии ... _обычно_ в портах есть разные опции сборки/flavors, когда используемые библиотеки и зависимости "зависят" от опций: pkg info xterm ... Options        :     256COLOR       : on     DABBREV        : off     DECTERM        : off     GNOME          : off     LOGGING        : off     LUIT           : on     NEXTAW         : off     PCRE           : off     REGIS          : off     SCRNDUMP       : off     SIXEL          : off     TOOLBAR        : off     WCHAR          : on     XAW3D          : off     XAW3DXFT       : off     XINERAMA       : off /usr/ports/x11/xterm/Makefile PCRE_LIB_DEPENDS=        libpcre.so:devel/pcre XAW3D_LIB_DEPENDS=        libXaw3d.so:x11-toolkits/Xaw3d XAW3DXFT_LIB_DEPENDS=        libXaw3dxft.so:x11-toolkits/libxaw3dxft NEXTAW_LIB_DEPENDS=        libneXtaw.so:x11-toolkits/neXtaw WCHAR_LIB_DEPENDS=        libfreetype.so:print/freetype2 LIB_DEPENDS+=    libfontconfig.so:x11-fonts/fontconfig В том же ffmpeg c его 90+ опциями, вообще нет "обычного" LIB_DEPENDS, только OPT_XZY_LIB_DEPENDS.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 18:56
	Если включен некий флаг и слинковались с libfoo, то такую зависимость можно проставить автоматически, посмотрев список зависимостей ELFов.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от анонн. (?), 02-Окт-20, 20:01
	> Если включен некий флаг и слинковались с libfoo, то такую зависимость можно проставить автоматически, посмотрев список зависимостей ELFов. Хм. А узнать, что для сборки с этим флагом требуется поставить libfoo.so вы предлагаете с помощью libastral.so? :) https://www.freebsd.org/ports/ Each port listed here contains any patches necessary to make the original application source code compile and run on FreeBSD. Installing an application is as simple as typing make install in the port directory. Each port's Makefile automatically fetches the application source code, either from a local disk, CD-ROM or via ftp, unpacks it on your system, applies the patches, and compiles. If all went well, a simple make install will install the application and register it with the package system. For most ports, a precompiled package also exists, saving the user the work and time of having to compile anything at all.
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	183. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от mikhailnov (ok), 02-Окт-20, 21:34
	>> Если включен некий флаг и слинковались с libfoo, то такую зависимость можно проставить автоматически, посмотрев список зависимостей ELFов. > Хм. А узнать, что для сборки с этим флагом требуется поставить libfoo.so > вы предлагаете с помощью libastral.so? :) А там общие зависимости для сборки и runtime что ли? Я про запуск. Для сборки может быть нужен только заголовочный файл. А libastral, кстати, реализован в RPM в виде генераторов сборочных зависимостей, толку от них не много, но ничто не мешает сделать умный генератор, который, например, будет находить все -lfoo в исходниках.
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

	184. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 21:44
	> Хм. А узнать, что для сборки с этим флагом требуется поставить libfoo.so > вы предлагаете с помощью libastral.so? :) В альте для выяснения, что из установленного на системе это была именно libfoo.so.*, служит http://altlinux.org/buildreq -- и есть понимание, куда это двигать дальше. Скрипты, кстати, не совсем тривиальные, но при желании (например, по результатам осмотра в их естественной среде обитания) должны вполне себе портироваться на другие фрюниксы.
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

	191. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (191), 03-Окт-20, 00:55
	Ох и адище же. Остановитесь !
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	139. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 01:21
	> Справедливости ради, точные версии все же нужно прописать в манифесте пакета: Чудовищное отношение к человеческим времени, силам и вниманию :(
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	153. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 02-Окт-20, 01:43
	> Чудовищное отношение к человеческим времени, силам и вниманию :( Это прикол вроде вечного вертения на конце технологий ? Лучше уж действительно прописать железно, нафиг такие дистрибутивы.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 21:27
	>> Чудовищное отношение к человеческим времени, силам и вниманию :( > Лучше уж действительно прописать железно, нафиг такие дистрибутивы. Так и я о чём -- железно пишется скриптом, а вовсе не усталыми руками. Причём это утверждаю именно как практикующий админ. PS re #190: Вы не только не понимаете, Вы ещё и русский даже на "хорошо" не сдадите :(
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (-), 02-Окт-20, 23:35
	я понимаю что вы бесконечно далеки от разработки и применения но надо было предупредить заранее что на столько.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Anm (?), 01-Окт-20, 08:30
	В pc-bsd был установщик pbi , вот это действительно было прогрессивно и надёжно.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

17. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
Сообщение от Рева RarogCmex Денис (?), 30-Сен-20, 19:04
Ждём ёбилдов
Ответить | Правка | Наверх | Cообщить модератору

	20. "Выпуск пакетного менеджера RPM 4.16"	+3 +/–
	Сообщение от Аноним (20), 30-Сен-20, 19:45
	Ты сам как ебилд
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (86), 01-Окт-20, 11:07
	sed -E 's/([[:alpha:]]*)([[:alpha:]])/\2\1/g'
	Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск пакетного менеджера RPM 4.16"	+2 +/–
Сообщение от Аноним (21), 30-Сен-20, 20:09
вместо 'a == b' теперь нужно писать '"a" == "b"' а что, без " они угнетали меньшинства или где? Изменение выглядит как какая-то дичь.
Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск пакетного менеджера RPM 4.16"	–9 +/–
Сообщение от BlackRot (ok), 30-Сен-20, 20:54
Научили бы его скорее работать с репами, очень жду
Ответить | Правка | Наверх | Cообщить модератору

	37. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (7), 01-Окт-20, 01:28
	Да, давай тащить в RPM весь функционал, что ни попадя: createrepo_c, dnf, mock, rpmdevtools, rpmlint, koji, repoview, fedpkg, ...
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от 1 (??), 01-Окт-20, 09:08
	ну и systemd заодно
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (86), 01-Окт-20, 11:09
	Тащить, конечно, не надо, но вот это "что угодно" было бы неплохо избавить от лишних зависимостей. createrepo_c хочет glib, dnf — аж целый python3…
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	95. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:25
	> Научили бы его скорее работать с репами, очень жду Если мир не рехнётся окончательно, то не научат никогда, это не уровень менеджера _пакетов_.  То же самое касается dpkg.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

32. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
Сообщение от Аноним (32), 01-Окт-20, 00:38
Он уже может работать хотя бы не в 5 раз медленнее xbps?
Ответить | Правка | Наверх | Cообщить модератору

	38. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (86), 01-Окт-20, 01:29
	dnf не может. zypper может.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Денис (??), 01-Окт-20, 03:14
	urpmi тоже довольно быстрый.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Выпуск пакетного менеджера RPM 4.16"	+3 +/–
	Сообщение от my_name_is_Mud (ok), 01-Окт-20, 11:10
	Быстрый, но мёртвый
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Денис (??), 01-Окт-20, 13:19
	> Быстрый, но мёртвый Да. Точнее глючный. А жаль.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Выпуск пакетного менеджера RPM 4.16"	+1 +/–
	Сообщение от Аноним (86), 01-Окт-20, 11:10
	Только мёртвый. Хотя, если серьёзно, он намного тормознее, чем zypper или apt. До dnf ему всё равно далеко, конечно…
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

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

	43. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от mikhailnov (ok), 01-Окт-20, 02:52
	Если вы из него вырежите большую часть функционала, сделав таким же примитивным, то почему бы и нет.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	52. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
	Сообщение от n00by (ok), 01-Окт-20, 10:13
	Что-то ты сам до сих пор не смог вырезать из RPM5 дичайшую амплификацию записи, из-за которой установка пакетов тормозила раз в 30, а Свеженькая Роза вставала колом. Так и барыжишь чужой костыль, на который у тебя нет прав.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от my_name_is_Mud (ok), 01-Окт-20, 11:12
	Роса сделали хитрее, вместо вырезания чего-то там из RPM5 они просто вырезали сам RPM5
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от n00by (ok), 01-Окт-20, 12:43
	Тоже мне, хитрость великая. Если они не способны исправить даже тривиальное переполнение стека в RPM5 (которое они же и внесли), у них банально нет иного выбора. Фанаты Мандривы уже окрестили сей процесс "офедоривание". ;) И да, "вырезали" будет после релиза, который по плану был 2 года назад, если шаражка в очередной раз вдруг не обанкротится.
	Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
Сообщение от Аноним (58), 01-Окт-20, 11:08
я так и не понял чем он лучше pacman-a
Ответить | Правка | Наверх | Cообщить модератору

	72. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Денис (??), 01-Окт-20, 13:33
	Пустые папки после удаления не оставляет. И мамки тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:27
	> я так и не понял чем он лучше pacman-a Например, поддержкой подпакетов.  Из одного этого следует столько, что можно не продолжать.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	103. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
	Сообщение от Аноним (58), 01-Окт-20, 16:29
	подпакеты ? а поддержка сверхпакетов есть ?
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 01:23
	> подпакеты ? а поддержка сверхпакетов есть ? Ну уж метапакеты-то не уметь -- это надо совсем слакварью быть.  Хотя как-то же там должны были "буковки" быть обеспечены, или прямо в инсталяторе забито было?
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
	Сообщение от Аноним (58), 02-Окт-20, 01:58
	надеюсь ты в курсе что профита от них меньше чем разговоров о выеденном яйце
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 21:28
	И от подпакетов, и от метапакетов польза есть и она огромна. Если, разумеется, руки растут откуда надо.
	Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск пакетного менеджера RPM 4.16"	–3 +/–
Сообщение от Аноним (61), 01-Окт-20, 12:25
apt наше всьо!
Ответить | Правка | Наверх | Cообщить модератору

	217. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 08-Окт-20, 18:53
	Наше все 1 текстовый файл с индексом пакетов? Нет уж, лучше sqlite
	Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск пакетного менеджера RPM 4.16"	–2 +/–
Сообщение от Аноним (-), 01-Окт-20, 13:04
Паетный менеджер Slackware самый оптимальный. DEB и RPM слишком переусложнены. В нёго понапихано много неиспользуемых фич.
Ответить | Правка | Наверх | Cообщить модератору

	94. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 15:22
	"I'm not a big believer in automated dependency handling." http://xpt.sourceforge.net/techdocs/nix/live/slax/slax02-Sla.../
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 01-Окт-20, 15:29
	> "I'm not a big believer in automated dependency handling." Ну это всё-таки вопросы технические, а не веры.  Брат Игорь так к ним и подходит: http://0x1.tv/Категория:Игорь_Власенко
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 17:38
	"В настоящее время на этой странице нет текста". Спасибо тебе брат Шигорин.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 01:25
	> "В настоящее время на этой странице нет текста". Уж не знаю, куда Вы умудрились уйти (потому как то, что хватает автолинкер -- это заглавная страница 0x1.tv, на которой текст есть; то, что представляет из себя полную ссылку -- разумеется, тоже не пустое ни разу), но извольте-с: http://tinyurl.com/yxh4zu5u
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 16:43
	Тоже отстой, Патрик перемудрил к сожалению и никто не поправил хороняку за три то десятка лет.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	111. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 17:40
	Патрег - бох! У Патрега всё оптимально, всё тютелька в тютельку, и здоровый консерватизм!
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Аноним (-), 01-Окт-20, 19:14
	Так никто и не спорит. Чуть чуть консервативнее надо было в некотором наборе строк и вообще было бы идеально. Либерализмам не место в софте.
	Ответить | Правка | Наверх | Cообщить модератору

107. "Выпуск пакетного менеджера RPM 4.16"	–1 +/–
Сообщение от swine (ok), 01-Окт-20, 17:03
Использующие portage смотрят ... Ну вы понели.
Ответить | Правка | Наверх | Cообщить модератору

	144. "Выпуск пакетного менеджера RPM 4.16"	+/–
	Сообщение от Michael Shigorin (ok), 02-Окт-20, 01:26
	> Использующие portage смотрят ... Ну вы понели. Да-да-да, в километры, мотающиеся в далёкую-далёкую галактику. Мы тоже так умеем, когда надо.
	Ответить | Правка | Наверх | Cообщить модератору

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

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