После года разработки состоялся релиз пакетного менеджера 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.me/opennews/art.shtml?num=53811
Чем он лучше pacman на десктопе?
Не лучше и не хуже, это другое.
Жаль
Пакман вроде очень примитивный по сравнению с рпм, был, во всяком случае.
>Пакман вроде очень примитивный по сравнению с рпмЗато научиться создавать пакеты для aur можно за 5 минут, а вот для rpm.....
вероятно это одна из причин по которой AUR помойка
это одна из причин почему человеков так много, их тоже легко делать
По слухам, все равно проще, чем для deb.
Для rpm очень легко создавать пакеты. Ну, смотря какие пакеты, кончно, но, вообще, просто.
Да ладно, вот моя болванка "спека с нуля":Name:Ничего умного...
Version:
Release: altSummary:
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
Это только для допотопных версий rpm актуально. Сейчас макросы поудобнее в ходу.
Вспомнил. В 1990-х гг. RPM называли примитивным, когда сравновали его с пакетным менеджером Debian-а.
> В 1990-х гг. RPM называли примитивным, когда сравновали его с пакетным
> менеджером Debian-а.Он не примитивный, он дубовый. А дебиановский по жизни называют результатом оверинжиниринга, хотя если посмотреть, когда там появились подписи -- то и в "овер-" можно было усомниться.
У каждого из них есть свои плюсы и минусы, при этом rpm тяготеет именно к дубовому краю шкалы, а dpkg -- к гибкому (дальше тот же портадж).
Кому непонятны плюсы дубовости -- посидите на стульчике из одних пружинок.
> Он не примитивный, он дубовый. А дебиановский по жизни называют результатом оверинжинирингаКто называет? Вообще-то всё ровно наоборот.
Не похожа сборка deb на гибкую. Ни макросов и env, ни генераторов зависимостей и провайдов.
Сборка deb — гибче некуда. Хочешь — руками архивы пакуй (ничего, кроме текстового редактора, tar и ar не надо), хочешь — скрипт напиши, хочешь — для облегчения задачи возьми dpkg-deb вместо архиватора, хочешь — используй dpkg-buildpackage, который запускает самый обычный make, для которого ты волен задавать какие тебе вздумается правила. Вместо макросов — вспомогательные утилиты для вызова из make-файла (прежде всего, конечно, dh, но не только; можешь сам скрипт написать и оттуда дёргать). Что ты подразумеваешь под env — в душе не чаю. Генераторы зависимостей есть. Генераторов провайдов нет, потому что там просто не принято пихать по сотне провайдов в пакет, вместо этого генераторы зависимостей более умные (находят не только нужный файл, но и пакет, к которому он принадлежит, и прописывают его явно).
А вот в rpm гибкости нет. Кроме rpmbuild ничем пакет не сделать. Никак кроме спека rpmbuild'у правила сборки не задать. В итоге, конечно, полному нубу намного легче освоить сборку rpm, но к гибкости это отношения не имеет.
> Сборка deb — гибче некуда.Заметьте вот это враньё.
> Вместо макросов
То есть даже макросов нет?
> Генераторы зависимостей есть. Генераторов провайдов нет
То есть и генераторы зависимостей наполовину лишены смысла (например, на сошки или .pm-ки).
> А вот в rpm гибкости нет. Кроме rpmbuild ничем пакет не сделать.
Так и тарбол руками вряд ли соберёте.
> Никак кроме спека rpmbuild'у правила сборки не задать.
Вы вообще не в теме, поэтому и пытаетесь пнуть куда попало.
RPM -- точнее, конкретно rpmbuild, это сильно отдельная программа и вполне заменимая чем-либо, что понадобится иного -- не туда пинать надо, что "фуу, без makefile этот ваш make бесполезен". А в то, что -- в отличие от make -- синтаксис спека является ad hoc и не подлежит описанию формальной грамматикой, что исключает возможность автоматического валидирования (да и полноценный разбор подразумевает возможность исполнения произвольного кода, хотя в частных случаях с этим кое-что получается сделать).
> В итоге, конечно, полному нубу намного легче освоить сборку rpm,
> но к гибкости это отношения не имеет._Полному_ нубу намного легче нести пургу вроде вышеразобранной, увы.
Особенно насчёт "некуда".
В debian/rules часто достаточно прописать стандартную заглушку, и оно само решит, вызывать make, meson и пр., поэтому лично мне было проще осаоить сборку deb, но сейчас с rpm приятнее работать.
Как в debian/rules прописать путь к директории с корнем будущего пакета, почему его нужно угадать и почему он не вынесен в переменную окрудения (env)? В rpm это макрос %buildroot или эквивалентная переменная окружения RPM_BUILD_ROOT. Как прописать путь к стандартному расположению библиотек? Нужно вручную прописать /usr/lib/x86_64-linux-gnu и понадеяться, что не ошибся, да еще и для каждой архитектуры отдельный вариант сделать вручную, когда как в rpm просто макрос %_libdir. А задача упаковывать deb в обход dpkg-buildpackage весьма странная, попахивает корявой сборкой пакета, но иногда может быть полезно, согласен.
Да что ж вы, только 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)))))
Спасибо за столь развернутое доказательство моей правоты. Билдрут много где в спеках пишут, создать папку и положить в нее файл - типовая операция.
Тьфу блин, тебе не переопределить, а получить? Так не надо ничего гадать, имя каталога совпадает с именем пакета. Только никто ни папки, ни мамки в rules не создаёт, для этого есть debian/<package>.install
> Спасибо за столь развернутое доказательство моей правоты.Хозяйке на заметку: с того же питерского IP, с которого пришло #200, в соседней теме про Эльбрус Линукс так же глупо пытаются вещать про "расследования".
А потом они искренне удивляются -- "а нас-то за шо"...
За всё и сразу.
> А вот в rpm гибкости нет. Кроме rpmbuild ничем пакет не сделать.emerge может собирать rpm пакеты.
Про emerge не знал. Но что он там, внутри себя, не дёргает всё тот же rpmbuild — не верю. А дёргать rpmbuild много кто умеет: cpack, fpm… Предварительно сформировав для него спек, само собой, иначе ведь он не работает.
rpm это всего лишь формат пакетов, альтернативой ему является tar. В зависимостях portage нет rpm. Лень смотреть, чем именно ebuild упаковывает в rpm файлы, собранные по *.ebuild. https://www.mankier.com/1/ebuild#Commands-rpm но rpmbuild там точно не используется -- он же не понимает *.ebuild.
Ну да, ну да…
https://github.com/gentoo/portage/blob/0bd5b693ef12c266000aa...
Ещё раз. Portage собирает RPM пакеты по спецификациям из файлов с расширением EBUILD. Такими буквами видно?Или Вам не ясна разница между исходным заявлением "Кроме rpmbuild ничем пакет не сделать" и "собрать пакет по .spec-у"?
Не надо мне ничего повторять ещё раз. Я уже написал, как это происходит: portage формирует спек и запускает rpmbuild. Если со зрением плохо, то вот создание спека: https://github.com/gentoo/portage/blob/0bd5b693ef12c266000aa...
А теперь сравни с deb. Там приблизительный аналог rpmbuild — dpkg-buildbpackage. Но можно обойтись и без него, запаковав содержимое каталога с файлами для установки и каталога с файлами метаданных с помощью dpkg-deb -b (никаких аналогов спека ему не надо, просто два каталога, и всё). А можно обойтись и без dpkg-deb, запаковав то же самое стандартными tar и ar, вообще на любой unix-образной системе, без необходимости устанавливать dpkg.
> А теперь сравни с 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 как минимум).
> Не надо мне ничего повторять ещё раз.В смысле, я разговариваю со стеной? Ничего подобного, я пишу читателям, кого может исходное "Кроме 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-файла.
> я пишу читателям, кого может исходное "Кроме rpmbuild ничем пакет не сделать" ввести в заблуждение.Ты пишешь:
> rpm это всего лишь формат пакетов, альтернативой ему является tar.Тем самым вводя читателей в заблуждение. tar — формат архивов, а не пакетов.
Ты пишешь:
> В зависимостях portage нет rpm
> rpmbuild там точно не используется -- он же не понимает *.ebuild.Это чушь собачья, что я и продемонстрировал выше.
И да, кроме rpmbuild rpm-пакет ничем не сделать. Любая обёртка будет вызывать rpmbuild. Никуда ты от этого не денешься. Ничем, кроме шестигранника, винт с шестигранным шлицем не закрутить, и даже если ты берёшь шуруповёрт, то всё равно вставляешь в него ту же шестигранную биту.
Ты так и не понял главного. rpm плох тем, что в нём нет нормального низкоуровневого инструмента для работы с пакетами. И вот это вот всё непотребство с созданием спека и вызовом rpmbuild в нутре portage, alien, cpack, fpm и прочего — костыли для обхода отсутствия такого инструмента. Это я пишу с точки зрения разработчика, копавшегося в коде подобных утилит, если что. Упаковка deb-пакета в них реализуется намного проще, чем rpm. Взять любую из них и подсчитать число строк кода, нужного для упаковки в тот и другой формат, предоставляю тебе.
>> я пишу читателям, кого может исходное "Кроме rpmbuild ничем пакет не сделать" ввести в заблуждение.
> Ты пишешь:
>> rpm это всего лишь формат пакетов, альтернативой ему является tar.
> Тем самым вводя читателей в заблуждение. tar — формат архивов, а не
> пакетов.Вы забыли указать принципиальную меж ними разницу. Потому что в данном контексте её нет.
> Ты пишешь:
>> В зависимостях portage нет rpm
>> rpmbuild там точно не используется -- он же не понимает *.ebuild.
> Это чушь собачья, что я и продемонстрировал выше.Вы там продемонстрировали, что для Вас rpm -- это готовый файлик, куда упакована уже собранная программа (в контексте Portage как раз аналог tar), а не сценарий её сборки с разрешением сборочных зависимости.
> И да, кроме rpmbuild rpm-пакет ничем не сделать.
> Это я пишу с точки зрения разработчика, копавшегося в коде подобных утилит, если что.Вы это пишите как пользователь, которому просто нафик не нужен был отдельный инструмент для упаковки готовых файликов в пакет, иначе же давно бы выкинули лишнее.
> Вы забыли указать принципиальную меж ними разницу. Потому что в данном контексте её нет.Разница в том, что пакет служит для установки софта в систему, а архив — для хранения произвольных файлов. Архив, в том числе tar, может являться пакетом, если содержит файлы для установки и метаданные для пакетного менеджера. В общем же случае — не является.
> Вы там продемонстрировали, что для Вас rpm -- это готовый файлик, куда упакована уже собранная программа (в контексте Portage как раз аналог tar), а не сценарий её сборки с разрешением сборочных зависимости.
Если говорить о пакете формата RPM, то да, любой пакет (не только rpm) — это готовый файлик, который существует совершенно независимо от сценария сборки. Потому что бывают нетиповые варианты создания пакетов, как в тех же portage или alien (это ведь не я их первым в качестве примера приводил, да?). Так вот, мы там что-то про гибкость тёрли, помнится. Под гибкостью обычно и подразумевают простоту адаптации к нетиповым сценариям использования. И, конечно, я именно о таких сценариях и пишу, чем демонстрирую, что помню контекст обсуждения.
> Вы это пишите как пользователь
Не буду.
>> Вы забыли указать принципиальную меж ними разницу. Потому что в данном контексте её нет.
> Разница в том, что пакет служит для установки софта в систему, а
> архив — для хранения произвольных файлов. Архив, в том числе tar,
> может являться пакетом, если содержит файлы для установки и метаданные для
> пакетного менеджера. В общем же случае — не является.У нас здесь частный случай, когда tar и rpm используются в одном сценарии.
>> Вы там продемонстрировали, что для Вас rpm -- это готовый файлик, куда упакована уже собранная программа (в контексте Portage как раз аналог tar), а не сценарий её сборки с разрешением сборочных зависимости.
> Если говорить о пакете формата RPM, то да, любой пакет (не только
> rpm) — это готовый файлик, который существует совершенно независимо от сценария
> сборки. Потому что бывают нетиповые варианты создания пакетов, как в тех
> же portage или alien (это ведь не я их первым в
> качестве примера приводил, да?).Да, я привёл пример Portage. В темах про Альт не раз видел претензии к rpm, мол, отсутствует гибкость, нельзя (точнее, сложно -- требует правки spec) сконфигурировать пакеты при сборке. На самом деле существует возможность собрать пакет используя дерева portage и USE-флаги. Аналогично и с alien.
> Так вот, мы там что-то про гибкость
> тёрли, помнится. Под гибкостью обычно и подразумевают простоту адаптации к нетиповым
> сценариям использования. И, конечно, я именно о таких сценариях и пишу,
> чем демонстрирую, что помню контекст обсуждения.Нетиповой сценарий использования микроскопа -- забивание гвоздей.
> Пакман вроде очень примитивный по сравнению с рпмВ чем примитивность?
зачем, зачем Вы задаёте такие вопросы, мистер Андерсон?
pacman нельзя сравнивать напрямую с rpm.
pacman это что-то вроде связки rpm + (zypper, yum, dnf).
zypper лучше тем, что в нём более понятный и интуитивный синтаксис, в отличие от packman, в котором его нужно просто тупо заучивать.
А также в zypper можно делать абсолютно все пакетные операции через команды, без необходимости править конфиги, при том править конфиги тоже можно с тем же результатом.
Сильная (и одновременно слабая) сторона zypper в том, что в ситуации, когда зависимости пакета разрешить невозможно, или произошла какая-то другая непредвиденная ситуация, он вместо того, чтобы сложить лапки к верху, как это делают другие пакетные менеджеры, предлагает пользователю проигнорировать условности и выстрелить себе в ногу.
По zypper (d)up все откатится, все равно.
> Сильная (и одновременно слабая) сторона zypper в том, что в ситуации, когда
> зависимости пакета разрешить невозможно, или произошла какая-то другая непредвиденная
> ситуация, он вместо того, чтобы сложить лапки к верху, как
> это делают другие пакетные менеджеры, предлагает пользователю проигнорировать условности
> и выстрелить себе в ногу.Вы написали глупость!
Он никогда не предлагает проигнорировать что-либо!
В случае невозможности решить конфликт пакетов или файлов он предлагает пользователю варианты решений одно из которых и по умолчанию a (Abort)!Он по умолчанию предлагает r (Retry) только при невозможности получить файл по curl (пакет или методанные репы), и только несколько раз, а потом предлагает a (Abort).
> 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-а выглядит более лаконичным и понятным
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 ExecOrLibNamesudo 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, а потом нужно что-то сделать с ним, то мгновенно вспоминаешь команды, потому что они, буквально, дословны и очевидны.
> 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
> 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 сам не догадается обновить базу перед обновлением системы.Просто великолепный как синтаксис, так и принцип работы...
И вы говорите что он понятный и его не нужно заучивать?
> 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 сам не догадается обновить базу перед обновлением системы.вы не понимаете что такое гибкий инструмент, возможно вам нужно было родится китайцем у которых иероглифы на все случаи жизни, и свою тетрадку использовали бы по назначению.
> И вы говорите что он понятный и его не нужно заучивать?
зачем вы заучиваете весь синтаксис пакетных менеджеров я не знаю, сам же я знаю всего с десяток ключей которые притом не заучивались а естественным образом за несколько использованний воспринимались а потом легко воспроизводились, это как азбука, если понял азы то можешь писать и читать любые книги без проблем.
не дописал, исправляю
> во первых, более полная база более тяжелая, например одна из оф.репа extra в сжатом виде весит 1656,0 KiB , а более полная уже 9,1 MiBво первых, полная база более тяжелая, например сейчас одна из оф.репа extra в сжатом виде весит 1656,0 KiB , а более полная уже 9,1 MiB, поэтому с ней работают локально а не на удаленном сервере
во вторых, -S подразумевает всё же работу с удалённой(находящейся на сервере) информацией.
И хоть она и скачана но ключ -Q также не подойдёт так как -Q это обращение к локальной базе установленных пакетов, а мы скачали полную с доп инфой по файлам
поэтому и выбрали -F как отдельная ветвь работы с полной базой локально.
> можно заменить на один:
> pacman -Syu пакет(ы)Это не мнемонично. Мнемонично так:
pacman -Suy пакет(ы)
Да какая разница. Ведь можно алиасы любые задать.
> -S
> -F
> -Q
> -R
> синтаксис pacman-а выглядит более лаконичным и понятнымЛишний shift мне лично лаконичным не кажется.
сделай себе голосовой ввод и проблема шифта отпадёт
> сделай себе голосовой ввод и проблема шифта отпадётАга, голосовой ввод в рутшелл. Там не только эта проблема отпадёт на первом же dd.
просто дикцию подтяни и сможешь быть с компьютером на ты
Мальчик, я был с компьютером "на ты" ещё при Союзе :-)
постой, это случайно не про тебя тогда писали в газете "Правда" о том что ты мысленно мог общаться с компьютером ЭВМ "МИР-2" ?
> Мальчик, я был с компьютером "на ты" ещё при СоюзеЭто получается лет в 10-13, так?
Железо того времени устроено существенно проще. Можно было разложить по полочкам в голове принципиальную схему клона Спектрума, или программировать в машинных кодах (без мнемоник) БК-0010. С тех пор сложность растёт, как и порог вхождения, только особо одарённые могут сейчас сходу на диалекте баш разрабатывать ОС.
>> я был с компьютером "на ты" ещё при Союзе
> Это получается лет в 10-13, так?Ага.
А интернет когда появился? Там ведь был сначала фидонет.
У меня в 2005 в виде диалапа, вместе с компом. Мне было 20. До этого увлекался только звукозаписью.
>> -S
>> -F
>> -Q
>> -R
>> синтаксис pacman-а выглядит более лаконичным и понятным
> Лишний shift мне лично лаконичным не кажется.А Вас не смущает что половина этих букв никак не ассоциируется с действием, которая она выполняет, а другая половина ассоциируется не верно?
> А Вас не смущает что ни одна из этих букв никак не ассоциируется с действием, которая она выполняет?ни одна ? странно, ведь, например, тот же ключ -R --remove очень красноречиво говорит о применении, или возможно у вас сформированы совершенно иные(инклюзивные) ассоциативные связи, в наш непростой век это нормально, для меня например совершенно непонятно почему использовали 'zypper dup' единственное что приходит на ум это dup(duplicate?) как дубликат хотя не совсем понятно что и кто дублируется. По описанию с того же сайта суси https://ru.opensuse.org/SDB:Zypper_использование_11.3
где написанно
"По команде “zypper dup” будет предпринята попытка синхронизировать уже установленные пакеты с пакетами, которые можно получить из (всех) репозиториев, которые вы включили."
на фоне этого ключ пакмана -S --sync выглядит на порядок понятным и логичным.
Да, ни одна.-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.
> dup это сокращение от dist-upgrade, можно написать и sudo zypper dist-upgrade, просто я люблю использовать краткий синтаксис.-R --remove первая буква со слова remove, для меня ассоциация очевидна, хотя и с recursive тоже нормально, но раз прописав команду уже больше не запутаешься, а вот с dup ...
теперь я понимаю почему у вас такие плотные ассоциации с тетрадкой, сочувствую>> на фоне этого ключ пакмана -S --sync выглядит на порядок понятным и логичным
> Не логично выглядит зачем этот ключ нужно указывать и почему он не указывается сам при -y и почему также вместе с ним не указывается -u.давайте еще раз попробую объяснить, а то вижу вам трудно
ключ -y есть, например, и у -F и он означает примерно то же самое - скачать базу, но только здесь она уже полная, то есть если указать просто ключ -y система(пакман) не поймёт какую базу качать.
Поэтому в пакман выделены главные(направляющие) ключи которые пишутся с большой буквы и они в команде взаимоисключают друг друга.
Да понял теперь как pacman устроен.
В zypper есть только полная база (хотя список файлов НЕ установленных пакетов она не показывает, только зависимости и что предоставляет) и она одна и таже и для поиска и для установки/обновления, по этому тут такого геморроя нет. Скачать лишние 10МБ, даже пусть 50МБ не проблема, особенно если в самом обновлении качаться будет гораздо больше, но это даёт возможность упростить работу с ПМ автоматически обновляя базу при обновлении/установке.
Мне такой подход нравится гораздо больше.
размер "полного" репозитория примерно в 5-10 раз больше по объёму от основного, в зависимости от количества пакетов. То есть в в зависимости от количества подключенных реп нагрузка на сеть/диск/процессор(распаковка) может значительно вырасти
я например использую по минимуму подключенные сторонние репы - 3 офрепы(core,extra,community) и одну левую seblu, выходит порядка 6MiB если качать полные то где-то 42MiB.
Здесь не проблема скачать базу, проблема в активном обновлении базы, если в репе обновляется хоть один пакет то нужно скачивать всю репу, то есть из трех оф.реп я не помню чтобы они в течении часа не обновились, на деле же это происходит намного чаще, конечно зависит от сервера с которого обновляешься и на сколько он часто запрашивает информацию про обновления, но нормальные сервера делают это довольно часто https://www.archlinux.org/mirrors/status/#successful
В общем такое разделение скорее всего обусловлено издержками дистрибутивов построенных на модели ролинг-релиз, особенно Арча который под это заточен.
В openSUSE Tumbleweed (тоже ролинг) основная репа Oss физически не может обновляться чаще чем раз в сутки, а если снапшот Factory не проходит QA, то он и вовсе пропускается и не попадает в Tumbleweed.
Раз в день, а то и реже, выполнить sudo zypper dup и подождать вместо 10 секунд, 30 секунд, но при этом получить полную базу для поиска, для меня не проблема.
По умолчанию в openSUSE ставится хрень которая обновляет автоматически, но я осознанно её нафиг сношу, обновляя только вручную и только когда мне это нужно и я готов к этому.
в openSUSE ролинг это всё же не основной способ распространения, отдельная ветка, нагрузка на сами сервера со стороны пользователей незначительная.
я например у себя также раз в день обновляю(yay -Syu) систему, ручками, люблю "контроль на пальцах", а всяких автоматических приблуд в Арче если сам не установишь не появится.
Но пользователи бывают разные, кому-то например нравится выводить каждую минуту(или несколько) инфу на коньки по новым пакетам или просто отслеживать инфу по появлению конкретного пакета, например, ядра чтобы только тогда делать обновления, вот тогда уже начинает иметь значение размер реп ибо гонять(качать, распаковывать) каждую минуту несколько мегабайт это всё же намного лучше чем несколько десятков мегабайт.
то есть, уже просто обычный мониторинг может серьёзно напрячь ресурсы пользователя не говоря уже о сервере который не резиновый.
> В openSUSE Tumbleweed (тоже ролинг) основная репа Oss физически не может обновляться чаще чем раз в суткиDVD openSUSE Tumbleweed вообще нереально скачать. Ссылка протухает за несколько часов, а торрентов нет. Раньше были (неофициально, если .torrent дописать), но прикрыли. Да и какой в них смысл, если там http зеркала напиханы, а торрент сидов нет. Через сервис offcloud.com если только, но он уже на ладан дышит.
> offcloud.comКстати, их сервер выкачивает 4.2 Гб за 1-2 минуты. Это 300-600 мбит/с получается.
Иногда такое бывает, когда они кривое зеркало подсовывают с которого очень низкая скорость загрузки.
Не понимаю. зачем вообще качать DVD?
Я всегда качаю сетевой установщик и закатываю его на флешку через dd когда нужно установить.
В rpm файловые зависимости.
Из-за этого их очень трудно читать. В 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 не гарант свежести.
Некоторые прогрессивные вообще на Ubuntu LTS сидят. А древность "освежают" снапом.
> В rpm файловые зависимости.Они более-менее в любом развесистом управителе авосек -- в dpkg тоже были, насколько помню. Кто-то их притом считает вредными. Возможно, готовить не умеют...
> в dpkg тоже были, насколько помнюПопей таблеточки, может, память улучшится. Нет и не было.
>> в dpkg тоже были, насколько помню
> Нет и не было.Действительно, если верить http://uneex.ru/static/PackageFormatComparison/index.html#it...
> Попей таблеточки, может, память улучшится.
PS: если я буду с _Вами_, юноша, дискутировать выписыванием таблеточек за хамство (п. 4 правил форума, см. ссылку вот под этой же формой) -- то полезное, что пытаетесь донести, получится прочесть только в логе модерирования. Пожалуйста, берегите себя и свои тексты -- тогда для других они будут полезней.
PPS: ну вот, при желании перепишите #146 как положено.
Кто-нибудь в курсе? Есть возможность проверить целостность файлов, установленных из пакета:
rpm -V пакет
или
rpm -Va
Проверяется, в частности, соответствие хэшей md5, сохраненных со времен установки пакета, тем, которые вычисляются по файлам при проверке. Проверить хэши можно. А извлечь?
Для каждого файла в пакете binutils показывает хэш:rpm -q --queryformat "[%{FILENAMES}\t%{FILEMD5S}\n]" binutils
Конкретно в федоре вместо MD5 по факту показывает SHA256.
Спасибо, выручили.
В RHEL6 тоже SHA256 обнаружилось вместо MD5.
rpm -q --dump
И Вам спасибо.
> ... в СУБД SQLite ... вместо бэкенда на основе BerkeleyDBНачалась перестановка кроватей.
Избавлениние от блокировок в базе.
> Избавлениние от блокировок в базе.Над Panu и компанией опытные разработчики порой посмеивались -- те усердно топчут _давно_ известные грабли, увы. И порой игнорируют предупреждения уже теперь.
> Реализован новый бэкенд
> Реализован новый экспериментальный бэкенд
> Удалён экспериментальный бэкенд
> Объявлен стабильным бэкендЭто такой творческий поиск методом научного тыка. Некогда думать, надо бэкенды реализовывать.
GUI для создания спек файлов не видно на горизонте?
Хорошоб чтоб vim и ко поддерживала нормально спек файлы, а ты сразу гуй.
Всё там нормально в vim, чего тебе не хватает?
> Хорошоб чтоб vim и ко поддерживала нормально спек файлы, а ты сразу гуй.apt-get install vim-plugin-spec_alt-ftplugin
Но зачем?
Для изучения основ, не читать же документацию бураттнам.
> GUI для создания спек файлов не видно на горизонте?apt-get install vim-X11
Ничего отстойнее в этом мире нет. Разве что только еще deb.
Но что круто ты нас недостойных не просвятиш.
setup.exe
InnoSetup и NSIS лучшие.
не знаю про nsis и inno, но стандартный вендовый MSI делается тоже не вот так просто... там ещё надо доков покурить чтобы сделать что-то простое
NSIS-установщик без доков тоже трудно вручную нормальный создать.
Расскажи, как ты с этими инструментами будешь устанавливать софт на Linux. Вообще-то, хотелось, чтобы простой и красивый стандартный установщик в Windows-стиле соществовал хотябы для популярных дистрибутивов (не flatpack, snap, appimage),чтобы было просто и красиво создавать проприоритарные пакеты как разработчику, так и устанавливать их пользователю.
В Qt есть установщик под Linux, но он ограничивается только Qt-софтом (устанавливал софт на нем - PDFMaker, FoxitReader). Даже на PyQt, PySide такой установщик создать не получится.
> Вообще-то, хотелось, чтобы простой и красивый стандартный установщик
> в Windows-стиле соществовал хотябы для популярных дистрибутивов.run изобретён в Loki Software точно больше полутора десятилетий назад.
> установщик
> устанавливать софт на LinuxЗа такое расстреливать полагается.
Ну не нравиться человеку он и выражает собственное фу. Хотя я бы на самом деле посмоетовал какое-то глобальное голосование сделать что бы вместо того что бы свой голос сувать в каждый топик про нелюбимую технологию он один раз проголосовал против RPM и один раз за любимый формат.Мне вот тоже DEB крайне раздражает, но за последние 10 лет я как-то уже привык.
Вы почитайте что сами пишете то. Какое голосование ? Извилина одна на толпу и та отторгается через раз. Вся это либерда билиберда уже никого не интересует, хоть обголосуйтесь до поноса, всем пофиг. Единственное что в толпе идиотов может быть и вменяемый человек, которому свободное мнение может быть полезно для как минимум не ощущения себя ненормальным в толпе идиотов. Вот что я думаю по этому поводу.
> Мне вот тоже DEB крайне раздражаетЧто он тебе раздражает?
Мне во фряхе pkg нравится, минималистичный, быстрый и ничего не сломает.
А вот это очень близко к истине. Всяко ближе чем весь этот рпм-деб шлак и помойка.
А PKG в чем архивирует в tar.gz просто?
Нет, как рыпымэ и дэб обворачивает любовью и словом добрым, укладывает почитывая молитвы и раздувая благовония. Откуда вы такие только беретесь, тушите свет, они лезут на свет !
И не умеющий банально следить, от какого so name зависимость, при смене версии библиотеки фряха запросто случайно перестает работать
dpkg тоже за этим не следит, однако Debian работать не перестаёт. Как так? АААА, МАГИЯ!!!P.S. Собственно, не знаю ни одного пакетного менеджера кроме rpm, который бы таким занимался. Оверинженеринг как он есть.
> dpkg тоже за этим не следит, однако Debian работать не перестаёт. Как
> так? АААА, МАГИЯ!!!Там, где не следят, но работать типа не перестает, например, в Arch Linux, это достигается за счет траты большого кол-ва людских ресурсов: если обновили ffmpeg, mpv может полежать пару часов не пересобранным, но его быстро пересоберут, большинство пользователей не заметит, зато будет пропагандировать быстрый pacman.
> зато будет пропагандировать
> быстрый pacman.Но ты ведь сам здесь и сейчас накидываешь на FreeBSD (и совершенно напрасно), в то время как _у_тебя_ systemd конфликтует при обновлении с systemd.
> если обновили ffmpeg, mpv может полежать пару часов не пересобраннымРечь, конечно, идет о мажорном обновлении. Потому что в пределах ветки либы совместимы.
Я как-то собирал "голый" ffmpeg. В смысле, без всяких внешних компонентов. С его либами собрал mpv.
Потом я набил руку и собрал жирнющий ffmpeg с чем только можно. Но mpv пересобирать не стал. Просто указал ему новые либы. И все работало. mpv стал играть AV1 (через libdav1d) чего раньше не умел, без всяких пересборок. Но с мажорным обновлением ffmpeg'а, например с 4 на 5, такое не прокатит.
>> если обновили ffmpeg, mpv может полежать пару часов не пересобранным
> Речь, конечно, идет о мажорном обновлении. Потому что в пределах ветки либы
> совместимы.Увы и ах. Однажды, в одном дистрибутиве обновили kodi, а ffmpeg остался "совместимой версии". При этом у одного из пользователей в видосиках из папки XXL тётеньки вдруг запели мужскими голосами. Тот бедняга слушал такое неделю и в итоге пришёл к гениальному выводу -- некий злодей взломал ему комп, что бы наказать его за непристойное поведение. mikhailnov почему-то, тыкая пальчиком в чужие mpv, не вспоминает эту замечательную историю. Вероятно, потому что он к ней причастен и там работает. ;)
Вообще кейс знаменит за пределами рунета, не конкретно прям вот так, не знаю подробностей - а именно приколы с ffmpeg - т.к он линкуется с кучей библиотек. И вот этот самый кейс от пакетного менеджера вообще не зависит, очень плохой пример.
> И вот этот самый кейс от пакетного менеджера вообще не зависит,
> очень плохой пример.А ввиду #138 -- наоборот, ffmpeg представляет хороший пример сложного случая. И как минимум один пакетный менеджер на планете его хорошо решает.
> И как минимум один пакетный менеджер на планете его хорошо решает.Прямые руки решают, а не пакетный менеджер. От того что там будет blah.so.0.1.1 в другом пакете blah.so.0.2.1 ничего в пакетном мире не поменяется.
Ах ну да, как это так, рпмушка будет одинакового названия. Сколько говорить - это проблемы пакетных менеджеров, созданные пакетными менеджерами и все вокруг их хотят решить с помощью пакетных менеджеров. Короче выкеньте это все на свалку и попробуйте юникс вей.
>> И как минимум один пакетный менеджер на планете его хорошо решает.
> Прямые руки решают, а не пакетный менеджер.*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.
Так говорят же русским языком - все это в пакетном менеджере не нужно. Еще марио оттуда запускать осталось.
> Вообще кейс знаменит за пределами рунета, не конкретно прям вот так, не
> знаю подробностей - а именно приколы с ffmpeg - т.к он
> линкуется с кучей библиотек.Ну да, интерфейс и реализация -- две большие разницы. Не только в случае ffmpeg, где неконсистентность выходит боком относительно часто, а в общем случае.
> И вот этот самый кейс от пакетного
> менеджера вообще не зависит, очень плохой пример.Кто понимает причины "кейса", тот может как-то его решать, с пакетным менеджером, или без оного. Остальным остаётся разглагольствовать про "ABI" и шукать по багтрекерам.
Либы с одинаковым so name не обязательно имеют совместимый ABI. В ALT есть механизм хеширования ABI и прописывания в зависимости пакета. В апстримном RPM максимум версионирование символов учтет, можно было бы написать генератор провайдов и зависимостей по ABI, но там нужен особый механизм сравнения хешей, не rpm vercmp, а каждый символ записывать в Provides и Requires слишком жирно (но можно попробовать на aarch64).
еще мультилиб туда запихнуть чтоб вот сразу и все. не нужно это пакетному менеджеру, все что он должен делать - распаковать ссылки и скинуть лог - все, не должно быть больше ничего.
> еще мультилиб туда запихнуть чтоб вот сразу и все. не нужно это
> пакетному менеджеру, все что он должен делать - распаковать ссылки и
> скинуть лог - все, не должно быть больше ничего.Сторонники такого подхода пользуются pacman и пр. максимально простыми пакетными менеджерами. Мне же хочется, чтобы пакетный менедже помогал держать систему работоспособной.
> Там, где не следят, но работать типа не перестает, например, в Arch Linux, это достигается за счет траты большого кол-ва людских ресурсов: если обновили ffmpeg, mpv может полежать пару часов не пересобранным, но его быстро пересоберут, большинство пользователей не заметит, зато будет пропагандировать быстрый pacman.И снова: в Debian такого не происходит. Да блин, что за магия-то?
На самом деле, вообще никакой связи с зависимостями от версий soшников. Решается всего лишь правильным именованием пакетов с либами. Вот в Fedora, например, на это забили болт, и никакой rpm им не помогает: до mass rebuild'а половина пакетов в rawhide неработоспособна.
Не тратьте время на повторы. Вот Вам анекдот:Здравствуйте!
Не могу установить системные обновления из-за конфликтующих пакетов.Следующие пакеты будут удалены для обновления остальных:
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...
Догадайтесь с трёх раз, кто автор сей характерной ошибки. :)
Через git blame авторов ошибки и исправлений поискал бы
Хочешь сказать, что это не смешно? Пользователи джва года мучаются, а ты тут умничаешь. Ну да, пользователям не смешно.
> Хочешь сказать, что это не смешно? Пользователи джва года мучаются, а ты
> тут умничаешь. Ну да, пользователям не смешно.Уже довольно давно не мучаются
>> Хочешь сказать, что это не смешно? Пользователи джва года мучаются, а ты
>> тут умничаешь. Ну да, пользователям не смешно.
> Уже довольно давно не мучаютсяБытие таково, что постоянно против твоих мрий.
1 окт
Однако в последнее время если правильно помню начиная с 11-й "свежести" начались какие-то странности. устанавливаешь все работает до первого большого обновления. если обновился штатно перестает запускаться, если systemd законфликтовал, запускается и работает нормально но в лотке всегда висит значек о наличии обновлений с этим самым systemd. В какой момент он начинает конфликтовать пока не понимаю.
https://vk.com/wall-33847957_317585
Примечательно, даже штатный УМВР-бот обломался.
Механизмы RPM функциональнее, универсальнее и проще дебиановского dh_shlibs
Это как посмотреть. У каждого подхода свои плюсы и минусы. Но проще однозначно дебиановский: он не вводит дополнительных сущностей, а оперирует только зависимостями от пакетов, идентифицируемых по имени, и их версий. Это затрудняет перекладывание файлов из одного пакета в другой, но зато упрощает и ускоряет разрешение зависимостей.
> Это как посмотреть. У каждого подхода свои плюсы и минусы. Но проще
> однозначно дебиановский: он не вводит дополнительных сущностей, а оперирует только зависимостямиЭто дебиановское что-ли ? Проще ? Это вот та какуля на какуле через какулю в структуре какуль - простая и понятная ? Да вы гоните
Я не знаю, про какие ты там какули (анальная фиксация?), но мы тут вообще-то о зависимостях пакетов. Так вот, вот это:
$ 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 отдельно указываются зависимости для *каждого* скриптлета, то там картина ещё сильнее усложняется.
> Это вот та какуля на какуле через какулю в структуре какуль -
> простая и понятная ? Да вы гонитеХозяйке на заметку: среди разработчиков и админов точно есть такие, которым удобней работать со структурой объектов, и такие, кому удобней воспринимать структурированный объект (но один).
Применительно к этому вопросу -- я в http://altlinux.org/m-p делал структуру объектов, pilot@ в http://altlinux.org/etcnet делал структуру объектов; соответственно на нас ругались те, кому удобней в mcedit найти что-либо в одной простынке, и те, кому милей дебиановская сетевая конфигурация опять же одной простынёй.
То есть как минимум стоит учитывать, что тут и впрямь есть развилка и разным людям ближе плюсы разных вариантов. Ну и что привычки -- тоже штука страшная (например, монолитный spec-файл тому же мне давно привычен, хотя это как раз "простынный" подход, а не "впорубку с будкой").
PS re #154: покажите-ка зависимости "каждого скриптлета" -- если так назвали Requires(pre), то это _возможность_, а не обязанность (полезная для ранних пакетов в графе зависимостей). Да, и в проиллюстрированном примере в дебиане умно оптимизировали зависимости, спрятав тот же coreutils за perl:any, или тупо врут (как вот про rpm2cpio)?
PPS: м-да, этот дебианщик оказался всё-таки глупой малолеткой, которая в жизни со своей "аргументацией" (и неумением воспринимать иную) явно ещё не раз будет рисковать своим таблом :(
> То есть как минимум стоит учитывать, что тут и впрямь есть развилка
> и разным людям ближе плюсы разных вариантов.Это же курс школьной психологии, дихотомии Юнга (правда, на фоне верований в ученье Маркса "материя для всех и при любом раскладе первична", теорию в своё время скомпрометировали). Отсюда же и противостояние командной строки с граф.интерфейсом, и феномен популярности Delphi в России. Интересно, что как раз здесь (на Опеннет) большинство должно быть в состоянии самостоятельно прийти к выводу о "развилках", но наблюдается обратное.
> Это же курс школьной психологии, дихотомии Юнга (правда, на фоне верований вПока вы тут псевдофилософствуете, конкуренты подсаживают твоих близких на всякие неведомые помои, т.к помои твоего производства можно псевдопонять через призму непонятных философствований но не здравый смысл и здорые потребности.
А я смотрю, кое-кто аж прям светится через эту свою призму. ;)
> А я смотрю, кое-кто аж прям светится через эту свою призму. ;)Нет, мне обидно за здравый смысл.
Разве я где-то тут табличку "доктор" нарисовал? Идите и поплачьте в уголке о безвозвратной утрате.
> На самом деле, вообще никакой связи с зависимостями от версий soшников.
> Решается всего лишь правильным именованием пакетов с либами.Да щазз, сколько апстримов с библиотеками dsohowto не читали...
В альте изобрели set versions, исключив этот класс проблем (к слову о генераторах, ага).
> И не умеющий банально следить, от какого 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> при смене версии библиотеки фряха запросто случайно перестает работать
В перепончатых мечтах, разве что.
База на то и база, что обновляется целиком и работает отдельно от всего остального.
Спасибо, забыл про это.
> Спасибо, забыл про это.Справедливости ради, точные версии все же нужно прописать в манифесте пакета:
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.
--
Не знал, что там так можно, но пользы вот от такого, как в примере, не вижу. Неизменная старшая цифра версии указывает на сохранение обратной совместимости, но не прямой. Соответственно, такая зависимость не помешает установить бинарь в систему с более старой версией библиотеки, нежели та, с которой он был собран, и есть вероятность, что работать он не сможет.
А что там с версионированием символов, кстати? rpm и про него знает.
> Не знал, что там так можно, но пользы вот от такого, как
> в примере, не вижу. Неизменная старшая цифра версии указывает на сохранение
> обратной совместимости, но не прямой. Соответственно, такая зависимость не помешает установить бинарь в систему с более старой версией библиотеки, нежели та, с которой он был собран, и есть вероятность, что работать он не сможет.Для этого есть версии самих пакетов.
"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.
Так и зачем тогда эта информация о либах, если всё равно надо указывать зависимости от содержащих их пакетов? В rpm весь профит как раз в том, что пакеты не прописываются, а зависимости от либ генерятся автоматически. В deb, наоборот, указывается только зависимость от пакетов с либами (версии не ниже той, с которой была сборка, тоже автоматически). А тут получается избыточность, да ещё и автоматизации никакой, как я понял.
Или таки я недопонял чего-то? Или ты что-то недорассказал?
> Так и зачем тогда эта информация о либах, если всё равно надо
> указывать зависимости от содержащих их пакетов? В rpm весь профит как
> раз в том, что пакеты не прописываются, а зависимости от либ генерятся автоматически. В deb, наоборот, указывается только зависимость от пакетов с либами (версии не ниже той, с которой была сборка, тоже автоматически). А тут получается избыточность, да ещё и автоматизации никакой, как я
> понял. Или таки я недопонял чего-то? Или ты что-то недорассказал?Зависимости указываются в билдфайле порта/пакета:
https://svnweb.freebsd.org/ports/head/devel/glib20/Makefile?...
LIB_DEPENDS+= libpcre.so:devel/pcre \
libffi.so:devel/libffiUSES+= 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
> Вот это - все, что прописывается "ручками" (причем, я бы не сказал, что glib "удачный" пример, но раз с него начали).
> Содержимое MANIFEST файла, с которым работает pkg (как и сам пакет) генерируется автоматически.А, так уже понятнее, спасибо. Хотя по-прежнему не до конца ясен смысл избыточности зависимостей при недостатке их версионности…
> Зависимости указываются в билдфайле порта/пакета:они про другое, про версию либы и мультиверсионность , зоопарк корочее. сразу видно что вот во фре этого бардака нет, а тут на лицо удобный тулзы для выгребания навоза.
Версии вручную надо прописать?
> Версии вручную надо прописать?Нет конечно. Но емнип, просто "по быстрому" указав список пакетов в зависимостях RUN_DEPENDS, списка shared lib c версиями в манифесте не будет.
>> Версии вручную надо прописать?
> Нет конечно. Но емнип, просто "по быстрому" указав список пакетов в зависимостях
> RUN_DEPENDS, списка shared lib c версиями в манифесте не будет.А зачем runtime зависимости от библиотек прописывать вручную? В чем проблема сосьавить его автоматически?
> А зачем 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.
Если включен некий флаг и слинковались с libfoo, то такую зависимость можно проставить автоматически, посмотрев список зависимостей ELFов.
> Если включен некий флаг и слинковались с 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.
>> Если включен некий флаг и слинковались с libfoo, то такую зависимость можно проставить автоматически, посмотрев список зависимостей ELFов.
> Хм. А узнать, что для сборки с этим флагом требуется поставить libfoo.so
> вы предлагаете с помощью libastral.so? :)А там общие зависимости для сборки и runtime что ли? Я про запуск. Для сборки может быть нужен только заголовочный файл.
А libastral, кстати, реализован в RPM в виде генераторов сборочных зависимостей, толку от них не много, но ничто не мешает сделать умный генератор, который, например, будет находить все -lfoo в исходниках.
> Хм. А узнать, что для сборки с этим флагом требуется поставить libfoo.so
> вы предлагаете с помощью libastral.so? :)В альте для выяснения, что из установленного на системе это была именно libfoo.so.*, служит http://altlinux.org/buildreq -- и есть понимание, куда это двигать дальше.
Скрипты, кстати, не совсем тривиальные, но при желании (например, по результатам осмотра в их естественной среде обитания) должны вполне себе портироваться на другие фрюниксы.
Ох и адище же. Остановитесь !
> Справедливости ради, точные версии все же нужно прописать в манифесте пакета:Чудовищное отношение к человеческим времени, силам и вниманию :(
> Чудовищное отношение к человеческим времени, силам и вниманию :(Это прикол вроде вечного вертения на конце технологий ? Лучше уж действительно прописать железно, нафиг такие дистрибутивы.
>> Чудовищное отношение к человеческим времени, силам и вниманию :(
> Лучше уж действительно прописать железно, нафиг такие дистрибутивы.Так и я о чём -- железно пишется скриптом, а вовсе не усталыми руками.
Причём это утверждаю именно как практикующий админ.
PS re #190: Вы не только не понимаете, Вы ещё и русский даже на "хорошо" не сдадите :(
я понимаю что вы бесконечно далеки от разработки и применения но надо было предупредить заранее что на столько.
В pc-bsd был установщик pbi , вот это действительно было прогрессивно и надёжно.
Ждём ёбилдов
Ты сам как ебилд
sed -E 's/([[:alpha:]]*)([[:alpha:]])/\2\1/g'
вместо 'a == b' теперь нужно писать '"a" == "b"'
а что, без " они угнетали меньшинства или где? Изменение выглядит как какая-то дичь.
Научили бы его скорее работать с репами, очень жду
Да, давай тащить в RPM весь функционал, что ни попадя: createrepo_c, dnf, mock, rpmdevtools, rpmlint, koji, repoview, fedpkg, ...
ну и systemd заодно
Тащить, конечно, не надо, но вот это "что угодно" было бы неплохо избавить от лишних зависимостей. createrepo_c хочет glib, dnf — аж целый python3…
> Научили бы его скорее работать с репами, очень ждуЕсли мир не рехнётся окончательно, то не научат никогда, это не уровень менеджера _пакетов_. То же самое касается dpkg.
Он уже может работать хотя бы не в 5 раз медленнее xbps?
dnf не может. zypper может.
urpmi тоже довольно быстрый.
Быстрый, но мёртвый
> Быстрый, но мёртвыйДа. Точнее глючный.
А жаль.
Только мёртвый.
Хотя, если серьёзно, он намного тормознее, чем zypper или apt. До dnf ему всё равно далеко, конечно…
Не всегда
Если вы из него вырежите большую часть функционала, сделав таким же примитивным, то почему бы и нет.
Что-то ты сам до сих пор не смог вырезать из RPM5 дичайшую амплификацию записи, из-за которой установка пакетов тормозила раз в 30, а Свеженькая Роза вставала колом. Так и барыжишь чужой костыль, на который у тебя нет прав.
Роса сделали хитрее, вместо вырезания чего-то там из RPM5 они просто вырезали сам RPM5
Тоже мне, хитрость великая. Если они не способны исправить даже тривиальное переполнение стека в RPM5 (которое они же и внесли), у них банально нет иного выбора. Фанаты Мандривы уже окрестили сей процесс "офедоривание". ;)И да, "вырезали" будет после релиза, который по плану был 2 года назад, если шаражка в очередной раз вдруг не обанкротится.
я так и не понял чем он лучше pacman-a
Пустые папки после удаления не оставляет. И мамки тоже.
> я так и не понял чем он лучше pacman-aНапример, поддержкой подпакетов. Из одного этого следует столько, что можно не продолжать.
подпакеты ? а поддержка сверхпакетов есть ?
> подпакеты ? а поддержка сверхпакетов есть ?Ну уж метапакеты-то не уметь -- это надо совсем слакварью быть. Хотя как-то же там должны были "буковки" быть обеспечены, или прямо в инсталяторе забито было?
надеюсь ты в курсе что профита от них меньше чем разговоров о выеденном яйце
И от подпакетов, и от метапакетов польза есть и она огромна.
Если, разумеется, руки растут откуда надо.
apt наше всьо!
Наше все 1 текстовый файл с индексом пакетов? Нет уж, лучше sqlite
Паетный менеджер Slackware самый оптимальный. DEB и RPM слишком переусложнены. В нёго понапихано много неиспользуемых фич.
"I'm not a big believer in automated dependency handling."
http://xpt.sourceforge.net/techdocs/nix/live/slax/slax02-Sla.../
> "I'm not a big believer in automated dependency handling."Ну это всё-таки вопросы технические, а не веры. Брат Игорь так к ним и подходит: http://0x1.tv/Категория:Игорь_Власенко
"В настоящее время на этой странице нет текста".Спасибо тебе брат Шигорин.
> "В настоящее время на этой странице нет текста".Уж не знаю, куда Вы умудрились уйти (потому как то, что хватает автолинкер -- это заглавная страница 0x1.tv, на которой текст есть; то, что представляет из себя полную ссылку -- разумеется, тоже не пустое ни разу), но извольте-с: http://tinyurl.com/yxh4zu5u
Тоже отстой, Патрик перемудрил к сожалению и никто не поправил хороняку за три то десятка лет.
Патрег - бох! У Патрега всё оптимально, всё тютелька в тютельку, и здоровый консерватизм!
Так никто и не спорит. Чуть чуть консервативнее надо было в некотором наборе строк и вообще было бы идеально. Либерализмам не место в софте.
Использующие portage смотрят ... Ну вы понели.
> Использующие portage смотрят ... Ну вы понели.Да-да-да, в километры, мотающиеся в далёкую-далёкую галактику.
Мы тоже так умеем, когда надо.