The OpenNET Project / Index page

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



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

"Выпуск пакетного менеджера 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.ru/opennews/art.shtml?num=53811

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

Оглавление

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

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

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

3. Сообщение от Fracta1L (ok), 30-Сен-20, 17:37   –12 +/
Жаль
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

4. Сообщение от Аноним (4), 30-Сен-20, 17:49   +2 +/
Пакман вроде очень примитивный по сравнению с рпм, был, во всяком случае.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #22, #67, #216

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

6. Сообщение от Аноним (6), 30-Сен-20, 18:04   +4 +/
> ... в СУБД SQLite ... вместо бэкенда на основе BerkeleyDB

Началась перестановка кроватей.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #31

7. Сообщение от Аноним (7), 30-Сен-20, 18:09   +6 +/
Для каждого файла в пакете binutils показывает хэш:

    rpm -q --queryformat "[%{FILENAMES}\t%{FILEMD5S}\n]" binutils

Конкретно в федоре вместо MD5 по факту показывает SHA256.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #23, #47

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

9. Сообщение от RPMbuild (?), 30-Сен-20, 18:17   +2 +/
Избавлениние от блокировок в базе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #89

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

12. Сообщение от Аноним (12), 30-Сен-20, 18:38   +5 +/
Но зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #18

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

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

16. Сообщение от microsoft (?), 30-Сен-20, 18:57   +3 +/
Но что круто ты нас недостойных не просвятиш.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #33, #39

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

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

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

20. Сообщение от Аноним (20), 30-Сен-20, 19:45   +3 +/
Ты сам как ебилд
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #54

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

22. Сообщение от лютый жабби__ (?), 30-Сен-20, 20:13   –3 +/
>Пакман вроде очень примитивный по сравнению с рпм

Зато научиться создавать пакеты для aur можно за 5 минут, а вот для rpm.....

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #26, #29, #30, #82

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

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

26. Сообщение от Чебур (?), 30-Сен-20, 21:12   +8 +/
вероятно это одна из причин по которой AUR помойка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #58

27. Сообщение от Аноним (27), 30-Сен-20, 21:27   +2 +/
Мне во фряхе pkg нравится, минималистичный, быстрый и ничего не сломает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #34, #42, #46

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

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

30. Сообщение от Nxx (ok), 30-Сен-20, 22:43   +2 +/
Для rpm очень легко создавать пакеты. Ну, смотря какие пакеты, кончно, но, вообще, просто.

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

31. Сообщение от YetAnotherOnanym (ok), 30-Сен-20, 23:33   +/
> Реализован новый бэкенд
> Реализован новый экспериментальный бэкенд
> Удалён экспериментальный бэкенд
> Объявлен стабильным бэкенд

Это такой творческий поиск методом научного тыка. Некогда думать, надо бэкенды реализовывать.

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

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

33. Сообщение от Аноним (-), 01-Окт-20, 01:17   –1 +/
setup.exe
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #36

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

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

36. Сообщение от Аноним (18), 01-Окт-20, 01:27   +/
InnoSetup и NSIS лучшие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #50, #63

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

38. Сообщение от Аноним (86), 01-Окт-20, 01:29   +1 +/
dnf не может. zypper может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #44

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

Мне вот тоже DEB крайне раздражает, но за последние 10 лет я как-то уже привык.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #104, #124

40. Сообщение от Аноним (39), 01-Окт-20, 01:32   +/
А PKG в чем архивирует в tar.gz просто?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #105

41. Сообщение от mikhailnov (ok), 01-Окт-20, 02:49   +1 +/
rpm -q --dump
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #45

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

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

44. Сообщение от Денис (??), 01-Окт-20, 03:14   –1 +/
urpmi тоже довольно быстрый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #57, #59, #130

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

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

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

48. Сообщение от 1 (??), 01-Окт-20, 09:08   +/
ну и systemd заодно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

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

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

51. Сообщение от Денис (??), 01-Окт-20, 10:01   +/
По zypper (d)up все откатится, все равно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

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

53. Сообщение от Аноним (86), 01-Окт-20, 11:01   –1 +/
dpkg тоже за этим не следит, однако Debian работать не перестаёт. Как так? АААА, МАГИЯ!!!

P.S. Собственно, не знаю ни одного пакетного менеджера кроме rpm, который бы таким занимался. Оверинженеринг как он есть.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #76

54. Сообщение от Аноним (86), 01-Окт-20, 11:07   +/
sed -E 's/([[:alpha:]]*)([[:alpha:]])/\2\1/g'
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

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

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

57. Сообщение от my_name_is_Mud (ok), 01-Окт-20, 11:10   +3 +/
Быстрый, но мёртвый
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #71

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

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

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

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

62. Сообщение от Аноним (58), 01-Окт-20, 12:25   –4 +/
> 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-а выглядит более лаконичным и понятным

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #77, #85

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

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

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

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

И да, "вырезали" будет после релиза, который по плану был 2 года назад, если шаражка в очередной раз вдруг не обанкротится.

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

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

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

70. Сообщение от Аноним (-), 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

> при смене версии библиотеки фряха запросто случайно перестает работать

В перепончатых мечтах, разве что.
База на то и база, что обновляется целиком и работает отдельно от всего остального.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #75

71. Сообщение от Денис (??), 01-Окт-20, 13:19   +/
> Быстрый, но мёртвый

Да. Точнее глючный.
А жаль.

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

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

73. Сообщение от Денис (??), 01-Окт-20, 13:36   –2 +/
Из-за этого их очень трудно читать. В 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ообщить модератору
Родитель: #28 Ответы: #74

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

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

76. Сообщение от mikhailnov (ok), 01-Окт-20, 13:49   –1 +/
> dpkg тоже за этим не следит, однако Debian работать не перестаёт. Как
> так? АААА, МАГИЯ!!!

Там, где не следят, но работать типа не перестает, например, в Arch Linux, это достигается за счет траты большого кол-ва людских ресурсов: если обновили ffmpeg, mpv может полежать пару часов не пересобранным, но его быстро пересоберут, большинство пользователей не заметит, зато будет пропагандировать быстрый pacman.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #78, #80, #97

77. Сообщение от Ilya Indigo (ok), 01-Окт-20, 14:04   –2 +/
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ообщить модератору
Родитель: #62 Ответы: #100

78. Сообщение от n00by (ok), 01-Окт-20, 14:13   +1 +/
> зато будет пропагандировать
> быстрый pacman.

Но ты ведь сам здесь и сейчас накидываешь на FreeBSD (и совершенно напрасно), в то время как _у_тебя_ systemd конфликтует при обновлении с systemd.

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

79. Сообщение от Ilya Indigo (ok), 01-Окт-20, 14:16   –5 +/
> Сильная (и одновременно слабая) сторона zypper в том, что в ситуации, когда
> зависимости пакета разрешить невозможно, или произошла какая-то другая непредвиденная
>  ситуация, он вместо того, чтобы сложить лапки к верху, как
> это делают другие пакетные менеджеры, предлагает пользователю проигнорировать условности
> и выстрелить себе в ногу.

Вы написали глупость!
Он никогда не предлагает проигнорировать что-либо!
В случае невозможности решить конфликт пакетов или файлов он предлагает пользователю варианты решений одно из которых и по умолчанию a (Abort)!

Он по умолчанию предлагает r (Retry) только при невозможности получить файл по curl (пакет или методанные репы), и только несколько раз, а потом предлагает a (Abort).

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

80. Сообщение от Денис (??), 01-Окт-20, 15:02   +/
> если обновили ffmpeg, mpv может полежать пару часов не пересобранным

Речь, конечно, идет о мажорном обновлении. Потому что в пределах ветки либы совместимы.
Я как-то собирал "голый" ffmpeg. В смысле, без всяких внешних компонентов. С его либами собрал mpv.
Потом я набил руку и собрал жирнющий ffmpeg с чем только можно. Но mpv пересобирать не стал. Просто указал ему новые либы. И все работало. mpv стал играть AV1 (через libdav1d) чего раньше не умел, без всяких пересборок. Но с мажорным обновлением ffmpeg'а, например с 4 на 5, такое не прокатит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #108, #132

82. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:11   +1 +/
Да ладно, вот моя болванка "спека с нуля":
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

Ничего умного...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #86

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #88, #131

85. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:17   +1 +/
> -S
> -F
> -Q
> -R
> синтаксис pacman-а выглядит более лаконичным и понятным

Лишний shift мне лично лаконичным не кажется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #101, #112

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

87. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:18   –3 +/
> В rpm файловые зависимости.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #92

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

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

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

89. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:20   +1 +/
> Избавлениние от блокировок в базе.

Над Panu и компанией опытные разработчики порой посмеивались -- те усердно топчут _давно_ известные грабли, увы.  И порой игнорируют предупреждения уже теперь.

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

90. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:20   +1 +/
> Хорошоб чтоб vim и ко поддерживала нормально спек файлы, а ты сразу гуй.

apt-get install vim-plugin-spec_alt-ftplugin

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

91. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:21   +/
> GUI для создания спек файлов не видно на горизонте?

apt-get install vim-X11

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

92. Сообщение от Аноним (86), 01-Окт-20, 15:21   –2 +/
> в dpkg тоже были, насколько помню

Попей таблеточки, может, память улучшится. Нет и не было.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #137

93. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:22   +1 +/
> Вообще-то, хотелось, чтобы простой и красивый стандартный установщик
> в Windows-стиле соществовал хотябы для популярных дистрибутивов

.run изобретён в Loki Software точно больше полутора десятилетий назад.

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

94. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #68 Ответы: #98

95. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:25   +1 +/
> Научили бы его скорее работать с репами, очень жду

Если мир не рехнётся окончательно, то не научат никогда, это не уровень менеджера _пакетов_.  То же самое касается dpkg.

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

96. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:27   +/
> я так и не понял чем он лучше pacman-a

Например, поддержкой подпакетов.  Из одного этого следует столько, что можно не продолжать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #103

97. Сообщение от Аноним (86), 01-Окт-20, 15:28   +/
> Там, где не следят, но работать типа не перестает, например, в Arch Linux, это достигается за счет траты большого кол-ва людских ресурсов: если обновили ffmpeg, mpv может полежать пару часов не пересобранным, но его быстро пересоберут, большинство пользователей не заметит, зато будет пропагандировать быстрый pacman.

И снова: в Debian такого не происходит. Да блин, что за магия-то?
На самом деле, вообще никакой связи с зависимостями от версий soшников. Решается всего лишь правильным именованием пакетов с либами. Вот в Fedora, например, на это забили болт, и никакой rpm им не помогает: до mass rebuild'а половина пакетов в rawhide неработоспособна.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #109, #128, #138

98. Сообщение от Michael Shigorinemail (ok), 01-Окт-20, 15:29   +/
> "I'm not a big believer in automated dependency handling."

Ну это всё-таки вопросы технические, а не веры.  Брат Игорь так к ним и подходит: http://0x1.tv/Категория:Игорь_Власенко

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #110

99. Сообщение от Аноним (-), 01-Окт-20, 15:29   +1 +/
> Спасибо, забыл про это.

Справедливости ради, точные версии все же нужно прописать в манифесте пакета:


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ообщить модератору
Родитель: #75 Ответы: #117, #139

100. Сообщение от Аноним (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ообщить модератору
Родитель: #77 Ответы: #113, #172

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

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

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

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

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

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

108. Сообщение от n00by (ok), 01-Окт-20, 17:09   +/
>> если обновили ffmpeg, mpv может полежать пару часов не пересобранным
> Речь, конечно, идет о мажорном обновлении. Потому что в пределах ветки либы
> совместимы.

Увы и ах. Однажды, в одном дистрибутиве обновили kodi, а ffmpeg остался "совместимой версии". При этом у одного из пользователей в видосиках из папки XXL тётеньки вдруг запели мужскими голосами. Тот бедняга слушал такое неделю и в итоге пришёл к гениальному выводу -- некий злодей взломал ему комп, что бы наказать его за непристойное поведение. mikhailnov почему-то, тыкая пальчиком в чужие mpv, не вспоминает эту замечательную историю. Вероятно, потому что он к ней причастен и там работает. ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #145

109. Сообщение от n00by (ok), 01-Окт-20, 17:23   –1 +/
Не тратьте время на повторы. Вот Вам анекдот:

Здравствуйте!
Не могу установить системные обновления из-за конфликтующих пакетов.

Следующие пакеты будут удалены для обновления остальных:
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ообщить модератору
Родитель: #97 Ответы: #127

110. Сообщение от Аноним (-), 01-Окт-20, 17:38   +/
"В настоящее время на этой странице нет текста".

Спасибо тебе брат Шигорин.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #143

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

112. Сообщение от Ilya Indigo (ok), 01-Окт-20, 17:41   –1 +/
>> -S
>> -F
>> -Q
>> -R
>> синтаксис pacman-а выглядит более лаконичным и понятным
> Лишний shift мне лично лаконичным не кажется.

А Вас не смущает что половина этих букв никак не ассоциируется с действием, которая она выполняет, а другая половина ассоциируется не верно?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #114

113. Сообщение от 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ообщить модератору
Родитель: #100 Ответы: #118

114. Сообщение от Аноним (58), 01-Окт-20, 18:16   +/
> А Вас не смущает что ни одна из этих букв никак не ассоциируется с действием, которая она выполняет?

ни одна ? странно, ведь, например, тот же ключ -R --remove очень красноречиво говорит о применении, или возможно у вас сформированы совершенно иные(инклюзивные) ассоциативные связи, в наш непростой век это нормально, для меня например совершенно непонятно почему использовали 'zypper dup' единственное что приходит на ум это dup(duplicate?) как дубликат хотя не совсем понятно что и кто дублируется. По описанию с того же сайта суси https://ru.opensuse.org/SDB:Zypper_использование_11.3
где написанно
"По команде “zypper dup” будет предпринята попытка синхронизировать уже установленные пакеты с пакетами, которые можно получить из (всех) репозиториев, которые вы включили."
на фоне этого ключ пакмана -S --sync выглядит на порядок понятным и логичным.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #115

115. Сообщение от 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ообщить модератору
Родитель: #114 Ответы: #121

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

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

118. Сообщение от Аноним (58), 01-Окт-20, 20:25   +1 +/
> 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ообщить модератору
Родитель: #113 Ответы: #120

119. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #117 Ответы: #125, #129

120. Сообщение от Аноним (58), 01-Окт-20, 20:43   +/
не дописал, исправляю
>  во первых, более полная база более тяжелая, например одна из оф.репа extra в сжатом виде весит 1656,0 KiB , а более полная уже 9,1 MiB

во первых, полная база более тяжелая, например сейчас одна из оф.репа extra в сжатом виде весит 1656,0 KiB , а более полная уже 9,1 MiB, поэтому с ней работают локально а не на удаленном сервере
во вторых, -S подразумевает всё же работу с удалённой(находящейся на сервере) информацией.
И хоть она и скачана но ключ -Q также не подойдёт так как -Q это обращение к локальной базе установленных пакетов, а мы скачали полную с доп инфой по файлам
поэтому и выбрали -F как отдельная ветвь работы с полной базой локально.

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

121. Сообщение от Аноним (58), 01-Окт-20, 21:09   –1 +/
> dup это сокращение от dist-upgrade, можно написать и sudo zypper dist-upgrade, просто я люблю использовать краткий синтаксис.

-R --remove первая буква со слова remove, для меня ассоциация очевидна, хотя и с recursive тоже нормально, но раз прописав команду уже больше не запутаешься, а вот с dup ...
теперь я понимаю почему у вас такие плотные ассоциации с тетрадкой, сочувствую

>> на фоне этого ключ пакмана -S --sync выглядит на порядок понятным и логичным
> Не логично выглядит зачем этот ключ нужно указывать и почему он не указывается сам при -y и почему также вместе с ним не указывается -u.

давайте еще раз попробую объяснить, а то вижу вам трудно
ключ -y есть, например, и у -F и он означает примерно то же самое - скачать базу, но только здесь она уже полная, то есть если указать просто ключ -y система(пакман) не поймёт какую базу качать.
Поэтому в пакман выделены главные(направляющие) ключи которые пишутся с большой буквы и они в команде взаимоисключают друг друга.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #122

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

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

124. Сообщение от Sgt. Gram (?), 01-Окт-20, 22:55   +2 +/
> Мне вот тоже DEB крайне раздражает

Что он тебе раздражает?

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

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

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

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

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

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

130. Сообщение от mikhailnov (ok), 02-Окт-20, 00:33   +/
Не всегда
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #160

136. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:11   +1 +/
> сделай себе голосовой ввод и проблема шифта отпадёт

Ага, голосовой ввод в рутшелл.  Там не только эта проблема отпадёт на первом же dd.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #158

137. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:17   –2 +/
>> в dpkg тоже были, насколько помню
> Нет и не было.

Действительно, если верить http://uneex.ru/static/PackageFormatComparison/index.html#it...

> Попей таблеточки, может, память улучшится.

PS: если я буду с _Вами_, юноша, дискутировать выписыванием таблеточек за хамство (п. 4 правил форума, см. ссылку вот под этой же формой) -- то полезное, что пытаетесь донести, получится прочесть только в логе модерирования.  Пожалуйста, берегите себя и свои тексты -- тогда для других они будут полезней.

PPS: ну вот, при желании перепишите #146 как положено.

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

138. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:20   –1 +/
> На самом деле, вообще никакой связи с зависимостями от версий soшников.
> Решается всего лишь правильным именованием пакетов с либами.

Да щазз, сколько апстримов с библиотеками dsohowto не читали...

В альте изобрели set versions, исключив этот класс проблем (к слову о генераторах, ага).

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

139. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:21   +/
> Справедливости ради, точные версии все же нужно прописать в манифесте пакета:

Чудовищное отношение к человеческим времени, силам и вниманию :(

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #153

140. Сообщение от Денис (??), 02-Окт-20, 01:23   +/
> установщик
> устанавливать софт на Linux

За такое расстреливать полагается.

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

141. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:23   +/
> подпакеты ? а поддержка сверхпакетов есть ?

Ну уж метапакеты-то не уметь -- это надо совсем слакварью быть.  Хотя как-то же там должны были "буковки" быть обеспечены, или прямо в инсталяторе забито было?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #157

142. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #125 Ответы: #151, #152

143. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:25   +/
> "В настоящее время на этой странице нет текста".

Уж не знаю, куда Вы умудрились уйти (потому как то, что хватает автолинкер -- это заглавная страница 0x1.tv, на которой текст есть; то, что представляет из себя полную ссылку -- разумеется, тоже не пустое ни разу), но извольте-с: http://tinyurl.com/yxh4zu5u

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

144. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:26   +/
> Использующие portage смотрят ... Ну вы понели.

Да-да-да, в километры, мотающиеся в далёкую-далёкую галактику.

Мы тоже так умеем, когда надо.

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

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

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

148. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 01:29   +/
> И вот этот самый кейс от пакетного менеджера вообще не зависит,
> очень плохой пример.

А ввиду #138 -- наоборот, ffmpeg представляет хороший пример сложного случая.  И как минимум один пакетный менеджер на планете его хорошо решает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #163

149. Сообщение от анонн. (?), 02-Окт-20, 01:31   +/
> Версии вручную надо прописать?

Нет конечно. Но емнип, просто "по быстрому" указав список пакетов в зависимостях RUN_DEPENDS, списка shared lib c версиями в манифесте не будет.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #161

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

Это дебиановское что-ли ? Проще ? Это вот та какуля на какуле через какулю в структуре какуль - простая и понятная ? Да вы гоните

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #154, #179

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

А, так уже понятнее, спасибо. Хотя по-прежнему не до конца ясен смысл избыточности зависимостей при недостатке их версионности…

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

152. Сообщение от Аноним (-), 02-Окт-20, 01:39   +/

> Зависимости указываются в билдфайле порта/пакета:

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

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

153. Сообщение от Аноним (-), 02-Окт-20, 01:43   +/

> Чудовищное отношение к человеческим времени, силам и вниманию :(

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #180

154. Сообщение от Аноним (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ообщить модератору
Родитель: #150

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

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

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

159. Сообщение от 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 весьма странная, попахивает корявой сборкой пакета, но иногда может быть полезно, согласен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #200

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

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

А зачем runtime зависимости от библиотек прописывать вручную? В чем проблема сосьавить его автоматически?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #169

162. Сообщение от mikhailnov (ok), 02-Окт-20, 10:14   +1 +/
> еще мультилиб туда запихнуть чтоб вот сразу и все. не нужно это
> пакетному менеджеру, все что он должен делать - распаковать ссылки и
> скинуть лог - все, не должно быть больше ничего.

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

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

163. Сообщение от Аноним (-), 02-Окт-20, 10:50   –1 +/

> И как минимум один пакетный менеджер на планете его хорошо решает.

Прямые руки решают, а не пакетный менеджер. От того что там будет blah.so.0.1.1 в другом пакете blah.so.0.2.1 ничего в пакетном мире не поменяется.

Ах ну да, как это так, рпмушка будет одинакового названия. Сколько говорить - это проблемы пакетных менеджеров, созданные пакетными менеджерами и все вокруг их хотят решить с помощью пакетных менеджеров. Короче выкеньте это все на свалку и попробуйте юникс вей.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #182

164. Сообщение от Денис (??), 02-Окт-20, 11:34   +/
> В openSUSE Tumbleweed (тоже ролинг) основная репа Oss физически не может обновляться чаще чем раз в сутки

DVD openSUSE Tumbleweed вообще нереально скачать. Ссылка протухает за несколько часов, а торрентов нет. Раньше были (неофициально, если .torrent дописать), но прикрыли. Да и какой в них смысл, если там http зеркала напиханы, а торрент сидов нет. Через сервис offcloud.com если только, но он уже на ладан дышит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #165, #166

165. Сообщение от Денис (??), 02-Окт-20, 11:37   +/
> offcloud.com

Кстати, их сервер выкачивает 4.2 Гб за 1-2 минуты. Это 300-600 мбит/с получается.

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #174

169. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #161 Ответы: #177

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

171. Сообщение от n00by (ok), 02-Окт-20, 14:28   +/
> Вообще кейс знаменит за пределами рунета, не конкретно прям вот так, не
> знаю подробностей - а именно приколы с ffmpeg - т.к он
> линкуется с кучей библиотек.

Ну да, интерфейс и реализация -- две большие разницы. Не только в случае ffmpeg, где неконсистентность выходит боком относительно часто, а в общем случае.

> И вот этот самый кейс от пакетного
> менеджера вообще не зависит, очень плохой пример.

Кто понимает причины "кейса", тот может как-то его решать, с пакетным менеджером, или без оного. Остальным остаётся разглагольствовать про "ABI" и шукать по багтрекерам.

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

172. Сообщение от Аноним (86), 02-Окт-20, 15:51   +1 +/
> можно заменить на один:
> pacman -Syu пакет(ы)

Это не мнемонично. Мнемонично так:
pacman -Suy пакет(ы)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #193

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

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

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

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

Уже довольно давно не мучаются

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #195

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

178. Сообщение от анонн. (?), 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.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #183, #184

179. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 21:21   +1 +/
> Это вот та какуля на какуле через какулю в структуре какуль -
> простая и понятная ? Да вы гоните

Хозяйке на заметку: среди разработчиков и админов точно есть такие, которым удобней работать со структурой объектов, и такие, кому удобней воспринимать структурированный объект (но один).

Применительно к этому вопросу -- я в http://altlinux.org/m-p делал структуру объектов, pilot@ в http://altlinux.org/etcnet делал структуру объектов; соответственно на нас ругались те, кому удобней в mcedit найти что-либо в одной простынке, и те, кому милей дебиановская сетевая конфигурация опять же одной простынёй.

То есть как минимум стоит учитывать, что тут и впрямь есть развилка и разным людям ближе плюсы разных вариантов.  Ну и что привычки -- тоже штука страшная (например, монолитный spec-файл тому же мне давно привычен, хотя это как раз "простынный" подход, а не "впорубку с будкой").

PS re #154: покажите-ка зависимости "каждого скриптлета" -- если так назвали Requires(pre), то это _возможность_, а не обязанность (полезная для ранних пакетов в графе зависимостей).  Да, и в проиллюстрированном примере в дебиане умно оптимизировали зависимости, спрятав тот же coreutils за perl:any, или тупо врут (как вот про rpm2cpio)?

PPS: м-да, этот дебианщик оказался всё-таки глупой малолеткой, которая в жизни со своей "аргументацией" (и неумением воспринимать иную) явно ещё не раз будет рисковать своим таблом :(

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #206

180. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 21:27   +/
>> Чудовищное отношение к человеческим времени, силам и вниманию :(
> Лучше уж действительно прописать железно, нафиг такие дистрибутивы.

Так и я о чём -- железно пишется скриптом, а вовсе не усталыми руками.

Причём это утверждаю именно как практикующий админ.

PS re #190: Вы не только не понимаете, Вы ещё и русский даже на "хорошо" не сдадите :(

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #190

181. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 21:28   +/
И от подпакетов, и от метапакетов польза есть и она огромна.
Если, разумеется, руки растут откуда надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

182. Сообщение от Michael Shigorinemail (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ообщить модератору
Родитель: #163 Ответы: #189

183. Сообщение от mikhailnov (ok), 02-Окт-20, 21:34   +/
>> Если включен некий флаг и слинковались с libfoo, то такую зависимость можно проставить автоматически, посмотрев список зависимостей ELFов.
> Хм. А узнать, что для сборки с этим флагом требуется поставить libfoo.so
> вы предлагаете с помощью libastral.so? :)

А там общие зависимости для сборки и runtime что ли? Я про запуск. Для сборки может быть нужен только заголовочный файл.

А libastral, кстати, реализован в RPM в виде генераторов сборочных зависимостей, толку от них не много, но ничто не мешает сделать умный генератор, который, например, будет находить все -lfoo в исходниках.

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

184. Сообщение от Michael Shigorinemail (ok), 02-Окт-20, 21:44   +/
> Хм. А узнать, что для сборки с этим флагом требуется поставить libfoo.so
> вы предлагаете с помощью libastral.so? :)

В альте для выяснения, что из установленного на системе это была именно libfoo.so.*, служит http://altlinux.org/buildreq -- и есть понимание, куда это двигать дальше.

Скрипты, кстати, не совсем тривиальные, но при желании (например, по результатам осмотра в их естественной среде обитания) должны вполне себе портироваться на другие фрюниксы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #191

185. Сообщение от Аноним (86), 02-Окт-20, 22:24   +/
Ну да, ну да…
https://github.com/gentoo/portage/blob/0bd5b693ef12c266000aa...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #194

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

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

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

191. Сообщение от Аноним (191), 03-Окт-20, 00:55   +/
Ох и адище же. Остановитесь !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

192. Сообщение от Денис (??), 03-Окт-20, 01:36   +/
> Мальчик, я был с компьютером "на ты" ещё при Союзе

Это получается лет в 10-13, так?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #196, #197

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #198

195. Сообщение от n00by (ok), 03-Окт-20, 07:12   +/
>> Хочешь сказать, что это не смешно? Пользователи джва года мучаются, а ты
>> тут умничаешь. Ну да, пользователям не смешно.
> Уже довольно давно не мучаются

Бытие таково, что постоянно против твоих мрий.

1 окт

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

https://vk.com/wall-33847957_317585

Примечательно, даже штатный УМВР-бот обломался.

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

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

197. Сообщение от Michael Shigorinemail (ok), 03-Окт-20, 12:49   +/
>> я был с компьютером "на ты" ещё при Союзе
> Это получается лет в 10-13, так?

Ага.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #202

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

199. Сообщение от Michael Shigorinemail (ok), 03-Окт-20, 18:02   –1 +/
> А теперь сравни с 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ообщить модератору
Родитель: #198

200. Сообщение от Аноним (86), 03-Окт-20, 18:25   –1 +/
Да что ж вы, только 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ообщить модератору
Родитель: #159 Ответы: #203

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

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

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

205. Сообщение от 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ообщить модератору
Родитель: #198 Ответы: #207

206. Сообщение от n00by (ok), 04-Окт-20, 10:13   –1 +/
> То есть как минимум стоит учитывать, что тут и впрямь есть развилка
> и разным людям ближе плюсы разных вариантов.

Это же курс школьной психологии, дихотомии Юнга (правда, на фоне верований в ученье Маркса "материя для всех и при любом раскладе первична", теорию в своё время скомпрометировали). Отсюда же и противостояние командной строки с граф.интерфейсом, и феномен популярности Delphi в России. Интересно, что как раз здесь (на Опеннет) большинство должно быть в состоянии самостоятельно прийти к выводу о "развилках", но наблюдается обратное.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #208

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205 Ответы: #209

208. Сообщение от Аноним (-), 04-Окт-20, 13:22   +/
> Это же курс школьной психологии, дихотомии Юнга (правда, на фоне верований в

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206 Ответы: #210

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207 Ответы: #212

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

211. Сообщение от Аноним (-), 04-Окт-20, 17:38   +/
> А я смотрю, кое-кто аж прям светится через эту свою призму. ;)

Нет, мне обидно за здравый смысл.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210 Ответы: #214

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

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

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

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

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

Не буду.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #213

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

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

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

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

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

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

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

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

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

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

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

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

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

216. Сообщение от Вы забыли заполнить поле Name (?), 08-Окт-20, 18:52   +/
> Пакман вроде очень примитивный по сравнению с рпм

В чем примитивность?

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

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


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

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




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

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