The OpenNET Project / Index page

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



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

Оглавление

Инициатива по сокращению размера приложений в Fedora, opennews (??), 01-Авг-19, (0) [смотреть все]

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


21. "Инициатива по сокращению размера приложений в Fedora"  –1 +/
Сообщение от Аноним (1), 01-Авг-19, 11:26 
> Что значит "проанализировать дерево зависимостей"?

Цитата из новости. Тоже хотелось бы знать, что подразумевается под этим.

> У собранного пакета? Ну вот так хотя
> бы: https://github.com/htgoebel/rpmgraph

Эта штука строит граф Requires из spec-ов. Позже в новой версии разделяемой библиотеки изменились опции, и часть функционала из неё при сборке исчезла. По графу вроде всё ровно, но при запуске системный загрузчик не найдёт связи. Или пользователь через пол-года сообщит: «нажимаю 5-ю кнопку в 3-м меню и оно падает».

> Или речь про пакет до сборки? А как вы это представляете, анализировать
> configure.in / cmakefiles / etc эвристикой? Так это нереально. Тут только
> руками алгоритмом типа такого: собрать на системе где все стоит с
> нужными опциями сборки, посмотреть получившиеся зависимости, прописать их, удаляя лишние,
> если нужно, собрать на чистой системе (чем-нибудь типа mock) для проверки.
> Ну а для сборки всего дистрибутива с циклическими зависимостями уже более серьезный
> подход и инструменты нужны, конечно. Они есть (koji, например).. но все
> равно нужно делать много итераций сборки и в процессе вручную исправлять
> косяки.

По-моему, "нужно" и "приходится" -- две большие разницы.

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

35. "Инициатива по сокращению размера приложений в Fedora"  –6 +/
Сообщение от пох. (?), 01-Авг-19, 12:04 
>> бы: https://github.com/htgoebel/rpmgraph
> Эта штука строит граф Requires из spec-ов. Позже в новой версии разделяемой

нет, она строит граф из rpmdb. О чем написано в первой же строке ридми.
Если вы не понимаете, в чем разница - вам рано делать глубокомысленные выводы, вы базовый функционал-то изучите.

> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.

и граф надо строить заново. Что не так?

> По-моему, "нужно" и "приходится" -- две большие разницы.

приходится из-за циклических зависимостей всего от всего.
Поэтому никакой бутстрэп с нулевой фазы больше невозможен - вам нужна полная система с миллионом неведомых хреней, иначе прекрасные cmake/ninja/meson не запустятся и не смогут собрать /bin/ls.

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

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

66. "Инициатива по сокращению размера приложений в Fedora"  –1 +/
Сообщение от Аноним (1), 01-Авг-19, 15:06 
>>> бы: https://github.com/htgoebel/rpmgraph
>> Эта штука строит граф Requires из spec-ов. Позже в новой версии разделяемой
> нет, она строит граф из rpmdb. О чем написано в первой же
> строке ридми.
> Если вы не понимаете, в чем разница - вам рано делать глубокомысленные
> выводы, вы базовый функционал-то изучите.э

Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из Космоса, верно? А моё предположение, что люди тут понимают: сначала на базе спека собирается пакет, при установке которого заполняется база -- оно слишком опрометчиво оказалось.

>> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.
> и граф надо строить заново. Что не так?

Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только лишь библиотек.

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

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

> вам нужна полная
> система с миллионом неведомых хреней, иначе прекрасные cmake/ninja/meson не запустятся
> и не смогут собрать /bin/ls.
> В лучшем случае можно только научиться воспроизводимо пересобирать один отдельный пакет.

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

77. "Инициатива по сокращению размера приложений в Fedora"  +1 +/
Сообщение от Stax (ok), 01-Авг-19, 16:25 
> Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из
> Космоса, верно? А моё предположение, что люди тут понимают: сначала на
> базе спека собирается пакет, при установке которого заполняется база -- оно
> слишком опрометчиво оказалось.

Вы, наверное, плохо представляете объем зависимостей, которые создает rpm автоматически (find-requires и другие механизмы, в т.ч. для вытягивание зависимостей из результатов линковки для нативного кода, из анализа метаданных с описанием зависимостей для разных языков типа maven-файлов для java и т.п.). В requires в спеке они явно вписаны могут не быть (хорошо это или плохо - другой вопрос). А в rpmdb они будут.

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

>>> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.
>> и граф надо строить заново. Что не так?
> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только
> лишь библиотек.

Каких еще функций? Если программа линкуется с каким-нибудь libX11.so, не все ли равно, какие именно функции она оттуда собралась дергать? Это проблема линковщика, а на уровне пакетов достаточно зависимости уровня библиотек.

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

80. "Инициатива по сокращению размера приложений в Fedora"  –3 +/
Сообщение от пох. (?), 01-Авг-19, 16:44 
> Каких еще функций? Если программа линкуется с каким-нибудь libX11.so, не все ли
> равно, какие именно функции она оттуда собралась дергать? Это проблема линковщика,

это он glibc(и не только) versioning изобретает. Когда цифирки после .so ничего не означают, потому что линкуется принципиально не по soname, или soname по глупости или сознательно сделан неправильным, а надо уточнить, какую именно libX11 ему надо.

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

108. "Инициатива по сокращению размера приложений в Fedora"  +/
Сообщение от Michael Shigorinemail (ok), 01-Авг-19, 22:55 
> > Граф хорошо бы строить с учётом имён импортируепмых-
> > экспортируемых функций, а не только лишь библиотек.
> Каких еще функций?

Видимо, подразумевалось "импортируемых-экспортируемых".

> Если программа линкуется с каким-нибудь libX11.so, не все ли
> равно, какие именно функции она оттуда собралась дергать?

Некоторым из нас нет (в очередной раз сошлюсь на Лёшу Турбина и разработанный им в ALT-RPM механизм set-versions), но это совсем другая сказка: если бы человек озадачился несколькими прогонами apt-cache dot на своей убунте или что там у него, а затем прикинул хоть на пальцах среднепотолочное число функций на сошку -- то пытаться даже не визуализировать граф, а получать данные для него ему бы, скорее всего, расхотелось.

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

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

132. "Инициатива по сокращению размера приложений в Fedora"  +/
Сообщение от Аноним (1), 02-Авг-19, 17:41 
> Просто даже для тыщ пяти пакетов лет пятнадцать назад это было уже
> почти сплошное чёрное пятно из стрелочек в отдельных местах -- при
> картинке в размерах, которые я мог позволить себе тогда распечатать, а
> не хотя бы A0...

Когда у меня был Спектрум, я написал на бейсике программку, которая тупо выводила содержимое памяти на экран. Загружал бинарник от игрушки и тупо в это месиво смотрел. Потом я начал понимать, в каком месте у игрушки картинки, в каком непосредственно код. Это позволило мне здорово экономить время по поиску бессмертий в играх. Даже оставалось время, что бы делать уроки.

А тут я, разумеется, граф смотреть не собираюсь. Пусть железка его анализирует.

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

131. "Инициатива по сокращению размера приложений в Fedora"  +/
Сообщение от Аноним (1), 02-Авг-19, 17:34 
>> Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из
>> Космоса, верно? А моё предположение, что люди тут понимают: сначала на
>> базе спека собирается пакет, при установке которого заполняется база -- оно
>> слишком опрометчиво оказалось.
> Вы, наверное, плохо представляете объем зависимостей, которые создает rpm автоматически
> (find-requires и другие механизмы, в т.ч. для вытягивание зависимостей из результатов
> линковки для нативного кода, из анализа метаданных с описанием зависимостей для
> разных языков типа maven-файлов для java и т.п.). В requires в
> спеке они явно вписаны могут не быть (хорошо это или плохо
> - другой вопрос). А в rpmdb они будут.

Автоматически пусть хоть в Небесную Канцелярию звонят. Начинается всё с создаваемого методом тыка спека. Вот когда автоматически начнут создавать spec, и пересборка пакетиков не будет превращаться в Китайский Новый год, когда никаких обновлений нет, тогда у меня вопросы отпадут.

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

Знаю. Читал жалобы пользователей той же Росы, как urpmi --auto-orphans превращает систему в тыкву.

>>>> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.
>>> и граф надо строить заново. Что не так?
>> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только
>> лишь библиотек.
> Каких еще функций? Если программа линкуется с каким-нибудь libX11.so, не все ли
> равно, какие именно функции она оттуда собралась дергать?

Практика показала, что перед тем как дёрнуть, функция там должна присутствовать.

> Это проблема линковщика,
> а на уровне пакетов достаточно зависимости уровня библиотек.

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

79. "Инициатива по сокращению размера приложений в Fedora"  –1 +/
Сообщение от пох. (?), 01-Авг-19, 16:41 
> Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из Космоса, верно?

проще: они туда попадают не из спека.
Точнее, в редких-редких случаях - и из спека тоже.

> А моё предположение, что люди тут понимают: сначала на базе спека собирается пакет, при установке
> которого заполняется база

нет, не при установке. При сборке. Вы просто не в курсе довольно банальных особенностей технологии.

никакие современные пакетные менеджеры не ориентируются на описанные в spec или debian/* данные, они собирают их самостоятельно, после сборки программы и перед ее упаковкой в архив.
Никакой особой магии нет, используется компот из ldd, grep (не все зависимости у нас  разрешает ld - есть еще интерпретируемые языки) и так далее. Его поведением можно управлять, но обычно не нужно.

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

> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только лишь
> библиотек.

это слишком геморройно (и не поможет для пакета использующего numpy ;-) но у библиотек есть versioning:
libcrypt.so.1(GLIBC_2.2.5)(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.10)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
и так далее. Как видите, некоторые базовые меры предосторожности предпринимаются, хотя по задумке должно было хватать цифирок после .so, но это немодно и немолодежно.

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

133. "Инициатива по сокращению размера приложений в Fedora"  +/
Сообщение от Аноним (1), 02-Авг-19, 17:46 
>[оверквотинг удален]
> никакие современные пакетные менеджеры не ориентируются на описанные в spec или debian/*
> данные, они собирают их самостоятельно, после сборки программы и перед ее
> упаковкой в архив.
> Никакой особой магии нет, используется компот из ldd, grep (не все зависимости
> у нас  разрешает ld - есть еще интерпретируемые языки) и
> так далее. Его поведением можно управлять, но обычно не нужно.
> Вот результат всего этого - он, естественно, разный при малейших изменениях сборочной
> среды - и попадает потом из пакета в rpmdb (для графа
> нам, естественно, нужна именно она, а не отдельный пакет, поскольку мы
> хотим видеть зависимости зависимостей).

Это всё несущественные мелочи и детали реализации.

>> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только лишь
>> библиотек.
> это слишком геморройно

И чего такого в ELF принципиально отличного от PE (для которого приходилось решать сходную задачу, при том что нужный функционал из ldd пришлось реализовать самому)?

> (и не поможет для пакета использующего numpy ;-) но
> у библиотек есть versioning:
> libcrypt.so.1(GLIBC_2.2.5)(64bit)
> libc.so.6()(64bit)
> libc.so.6(GLIBC_2.10)(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libc.so.6(GLIBC_2.3.2)(64bit)
> и так далее. Как видите, некоторые базовые меры предосторожности предпринимаются, хотя
> по задумке должно было хватать цифирок после .so, но это немодно
> и немолодежно.

И этот же автор пишет ниже про Gentoo portage...

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

107. "Инициатива по сокращению размера приложений в Fedora"  –1 +/
Сообщение от Michael Shigorinemail (ok), 01-Авг-19, 22:50 
> Поэтому никакой бутстрэп с нулевой фазы больше невозможен -
> вам нужна полная система с миллионом неведомых хреней,
> иначе прекрасные cmake/ninja/meson не запустятся и не смогут
> собрать /bin/ls.

Не настолько пока всё-таки плохо, хотя безумцы и стараются изо всех сил.

По крайней мере на e2k бутстрапиться (начали в 2015) не так уж часто помогали пакеты из предыдущей стабильной ветки (p7, 2013--2015 в активной фазе).  Хотя заметил такое, что в перловке количество циклов и неприятных развесистостей заметно подросло между p7 и p8 -- и это в перловке, с питонами и протчая всё было достаточно сильно хуже, чтобы на глаз я различить не брался...

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

Да ладно, это теперь тоже немножко модно стало -- всяко не один (и даже не каждый второй, а потолще).

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

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

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




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

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