The OpenNET Project / Index page

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



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

Оглавление

Первый выпуск пакетного менеджера Deck, opennews (??), 07-Окт-16, (0) [смотреть все]

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


23. "Первый выпуск пакетного менеджера Deck"  +/
Сообщение от Michael Shigorinemail (ok), 08-Окт-16, 13:19 
> deck was built with two assumptions:

Автор хоть сравнивает его с давно существующим checkinstall, который был создан явно без таких предположений?

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

26. "Первый выпуск пакетного менеджера Deck"  +1 +/
Сообщение от pampa (ok), 08-Окт-16, 13:39 
>> deck was built with two assumptions:
> Автор хоть сравнивает его с давно существующим checkinstall, который был создан явно
> без таких предположений?

(я автор) checkinstall использует LD_PRELOAD для перехвата системных вызовов. Если coreutils собрать статически, или использовать вместо них статический бизибокс, то LD_PRELOAD работать не будет. У меня была задача сделать как можно проще и без каких-либо предположений об окружении (кроме чтого, что оно может запустить бинарник). Чтобы можно было например загрузить голое ядро с бизибоксом, бросить туда бинарник и оно заработало.

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

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

43. "Первый выпуск пакетного менеджера Deck"  +/
Сообщение от Аноним (-), 08-Окт-16, 23:17 
Возможно, вам как автору будет интересно мнение пользователя LFS.

Сижу на LFS с 2006 года, практически сразу (в 2006) почувствовал необходимость в а. сохранении информации о том, каким образом и с какими configure-флагами был собран софт, и б. пакетном менеджере для хранения списка фалов каждого установленного пакета.

Недостаток checkinstall/paco и подобных в том, что пакет собирается от рута (и уже на этапе сборки может поломать систему, пусть даже не системные файлы обновить, а просто какой-нибудь процесс прибить) и что список изменённых файлов мы узнаём лишь после установки, так что может потребоваться уйма времени на восстановление из бэкапов.

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

Ну и, как по мне, держать в LFS-системе go-компилятор лишь для пакетного менеджера перебор.

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

44. "Первый выпуск пакетного менеджера Deck"  +/
Сообщение от pampa (ok), 08-Окт-16, 23:35 
>[оверквотинг удален]
> файлы обновить, а просто какой-нибудь процесс прибить) и что список изменённых
> файлов мы узнаём лишь после установки, так что может потребоваться уйма
> времени на восстановление из бэкапов.
> Сам долго пользовался paco, но однажды паранойя одержала верх, и пересел на
> Slackware pkgtools (когда пакет ставится в DESTDIR и лишь потом переносится
> на основную систему). Сейчас использую самописный аналог, который собирает от непривилегированного
> пользователя и перед установкой показывает, какие файлы будут перезатёрты, какие добавлены
> и т.д., что очень удобно.
> Ну и, как по мне, держать в LFS-системе go-компилятор лишь для пакетного
> менеджера перебор.

У меня были примерно те-же проблемы, но собирать все в DESTDIR я так и не осилил. Не все пакеты умеют DESTDIR, некоторым после установки в DESTDIR нужно писать postinstall скрипты etc. Работы на порядок больше чем сборка и установка от рута по-живому. Проблему поломки при установке я решаю откатом на предыдущее состояние. Т.к. пакетный менеджер собран статически, он не ломается. На совсем крайний случай могу загрузиться в статический-же busybox и откатить поломку из него. Особой паранои не испытываю, т.к. у меня всегда храниться контрольная сумма и бэкап всех файлов системы, и я после каждой установки знаю что и как поменялось. Восстановить файлы я могу выборочно поштучно, если вижу, что make install сделал что-то странное.

Что до Go компилятора - достаточно распаковать официальный бинарный релиз в /opt и прописать несколько переменных окружения.

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

53. "Первый выпуск пакетного менеджера Deck"  +1 +/
Сообщение от Аноним (-), 09-Окт-16, 13:59 
> Не все пакеты умеют DESTDIR

Из 4 сотен установленных у меня пакетов DESTDIR не поддерживается, наверное, в 7. Из них в двух он поддерживается но прсто называется INSTALL_ROOT или как-то так.

> некоторым после установки в DESTDIR нужно писать postinstall скрипты etc

Три: install-info, ld-config, depmod плюс три g-специфичных: glib-update-schemes, gtk-update-icon-cache, gdk-pixbuf-query-loaders. Вызываются из самого пакетного менеджера, если в пакете в нужных каталогах (соответственно /usr/share/info, /usr/lib:/lib, /lib/modules, и т.д.) есть файлы. Большего не требовалось пока.

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

Но если начинать с нуля и нет особого желания ковыряться в особенностях работы всяких glib*, то действительно прописывать это всё напряжно.

> Проблему поломки при установке я решаю откатом на предыдущее состояние.

Установка загрузчика вашим образом не откатится. Хотя других примеров, наверное, и нет.

> Что до Go компилятора

Тут уже скорее мои личные комплексы, не знаю, насколько они распространены у других. Считаю, что системный/низкоуровневый софт должен быть написан на C/Shell/Perl. Максимум C++.

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

58. "Первый выпуск пакетного менеджера Deck"  –1 +/
Сообщение от Michael Shigorinemail (ok), 10-Окт-16, 15:48 
> Сам долго пользовался paco, но однажды паранойя одержала верх, и пересел на
> Slackware pkgtools (когда пакет ставится в DESTDIR и лишь потом переносится
> на основную систему). Сейчас использую самописный аналог, который собирает от
> непривилегированного пользователя и перед установкой показывает, какие файлы
> будут перезатёрты, какие добавлены и т.д., что очень удобно.

Возможно, покажется интересным: http://ftp.altlinux.org/pub/people/ldv/hasher/

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

46. "Первый выпуск пакетного менеджера Deck"  +/
Сообщение от angra (ok), 09-Окт-16, 00:18 
> Сканировать все файлы и считать хеши неэффективно, но зато надежно.

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

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

57. "Первый выпуск пакетного менеджера Deck"  +/
Сообщение от Michael Shigorinemail (ok), 10-Окт-16, 15:47 
>>> deck was built with two assumptions:
>> Автор хоть сравнивает его с давно существующим checkinstall, который был создан явно
>> без таких предположений?
> У меня была задача сделать как можно проще и без каких-либо предположений об окружении
> (кроме чтого, что оно может запустить бинарник). Чтобы можно было например загрузить
> голое ядро с бизибоксом, бросить туда бинарник и оно заработало.

Понял, спасибо.  В таком случае и на strace не заложишься...

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

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

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




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

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