форумы  помощь  поиск  регистрация  вход/выход  слежка

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

"Первый выпуск пакетного менеджера Deck"	+/–
Сообщение от opennews (??) on 07-Окт-16, 23:54
Сформирован (https://github.com/pampa/deck/releases/tag/0.1.0) первый выпуск проекта Deck (https://github.com/pampa/deck), в рамках которого развивается простой пакетный менеджер для дистрибутивов, практикующих установку программ из исходных текстов, таких как  Linux From Scratch. Deck не манипулирует пакетами как таковыми, а отслеживает изменения в файловой системе, связанные с установкой программ, давая возможность затем удалить установленные файлы и восстановить состояние изменённых в процессе установки файлов. Deck предоставляет пользователю три базовые команды: "deck scan", "deck commit" и  "deck uninstall". Первая команда используется для определения файлов, установленных, удалённых или изменённых по сравнению с прошлым состоянием ФС. Запустив "deck scan" до и после установки программы из исходных текстов утилита формирует список изменений. Команда "deck commit" позволяет запомним выявленные изменения и связать их с установленным приложением. В дальнейшем для удаления этого приложения можно воспользоваться командой "deck uninstall". Для реализации данной функциональности deck обеспечивает вычисление и хранение контрольных сумм и резервных копий для каждого системного файла. Утилита написана на языке Go и распространяется как общественное достояние. URL: https://github.com/pampa/deck/releases/tag/0.1.0 Новость: http://www.opennet.me/opennews/art.shtml?num=45289
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Первый выпуск пакетного менеджера Deck"	+3 +/–
Сообщение от Аноним (??) on 07-Окт-16, 23:54
О — Общественное достояние.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Первый выпуск пакетного менеджера Deck"	–8 +/–
Сообщение от олхнтп on 08-Окт-16, 00:26
плин подумал уже посмотреть эту хреновину для своих ARM-поделок, ага прям ЩАЗ я буду тащить go только радо этого
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Первый выпуск пакетного менеджера Deck"	+7 +/–
	Сообщение от Vee Nee on 08-Окт-16, 01:40
	Это же не питон. Зачем тащить Go, когда тащить нужно только результат его компиляции?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	20. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от Stax (ok) on 08-Окт-16, 12:37
	Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений и обновляемые библиотеки с привязками, а также маленькие, легко обновляемые приложения, когда go скомпилит вам КАЖДЫЙ бинарник в 20-мегабайтную хрень, каждую из которых придется обновлять целиком при необходимости обновить как приложение, так и библиотеку (из-за уязвимости, например). Это ведь именно то, что нужно для вашего ARM!
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	22. "Первый выпуск пакетного менеджера Deck"	+3 +/–
	Сообщение от pampa (ok) on 08-Окт-16, 12:41
	> Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений Питон нельзя собрать в один статический бинарник и бросить на голую систему и ядра и бизибокса
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	33. "Первый выпуск пакетного менеджера Deck"	–2 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 14:42
	>> Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений > Питон нельзя собрать в один статический бинарник Да что вы говорите! https://wiki.python.org/moin/BuildStatically
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	34. "Первый выпуск пакетного менеджера Deck"	+2 +/–
	Сообщение от pampa (ok) on 08-Окт-16, 14:49
	>>> Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений >> Питон нельзя собрать в один статический бинарник > Да что вы говорите! > https://wiki.python.org/moin/BuildStatically А теперь расскажите, как мне в этот-же бинарник засунуть питоновские либы и приложение на питоне.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	35. "Первый выпуск пакетного менеджера Deck"	–6 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 14:56
	Рецепт: берем 500 мегабайтный пакет питона (вместе со всем зависимости) и исполняемый файл приложения и пакуем всё в инсталлятор.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	38. "Первый выпуск пакетного менеджера Deck"	+4 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 15:08
	> Рецепт: берем 500 мегабайтный пакет питона (вместе со всем зависимости) О, вот и диванный теоретик подтянулся. Расскажи нам, как ты умудряешся собрать питон на 500 мб.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	37. "Первый выпуск пакетного менеджера Deck"	–3 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 15:06
	>>>> Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений >>> Питон нельзя собрать в один статический бинарник >> Да что вы говорите! >> https://wiki.python.org/moin/BuildStatically > А теперь расскажите, как мне в этот-же бинарник засунуть питоновские либы Прилинковать, не? > и приложение на питоне. Приложения на питоне, внезапно, совсем не бинарник.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	32. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Аноним (??) on 08-Окт-16, 14:41
	Вы описали крайнюю ситуацию. Либы GO можно прилинковать к исполняемому необновляемому файлу. А весь функциональный код приложения вынести в маленький подключаемый модуль, который и будет обновляться.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	42. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Stax (ok) on 08-Окт-16, 23:13
	Я описал то, что вижу в жизни. Почему-то 99% кода на go собирают вот так: $ ll /usr/bin/kubectl -rwxr-xr-x. 2 root root 46M июл 17 15:04 /usr/bin/kubectl Исключения, возможно, бывают. Но ВСЕ вокруг поголовно собирают именно так. Любые приложения на go, самых разных мастей. Видимо, "так принято". Понимаю, что можно иначе - но иначе, видимо, "не принято". Вот и все...
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	31. "Первый выпуск пакетного менеджера Deck"	–2 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 14:33
	Сanonical тащат 500 метров питона, они дураки?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	36. "Первый выпуск пакетного менеджера Deck"	+2 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 15:02
	> Сanonical тащат 500 метров питона, они дураки? Мне вот интересно, откуда они (или некоторые воинствующие анонимы) берут эти волшебные 500 метров? Ведь не первый раз на опеннете вижу. Я например полюбопытсвовал – и оказалось, что в репах под две тысячи питоно-пакетов (для второго питона), которые занимают в сумме 272 мб (причем, тот же рейнджер считается питонопакетом). А сам пакет с вторым питоном занимает у меня ~66мб (с третим - 79мб). Правда, у меня не каноникал, но все равно, маленькой репу (вернее, количество софта в ней) назвать нелься.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	45. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от angra (ok) on 09-Окт-16, 00:11
	Во-первых, ты смотришь на размер пакета, а не на результат его разворачивания. Умножь на 2 Во-вторых, ты почему-то игнорируешь третий питон, а так как программ на питоне может быть нужно значительно больше одной, то есть высокая вероятность, что понадобятся обе ветки питона. Умножь еще на 2.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	48. "Первый выпуск пакетного менеджера Deck"	–1 +/–
	Сообщение от Аноним (??) on 09-Окт-16, 01:09
	> Во-первых, ты смотришь на размер пакета, а не на результат его разворачивания. Неа. Любой мал-мальский пакетник показывает "Installed Size". > понадобятся обе ветки питона. Умножь еще на 2. И даже так 500 мб никак не набираются.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	9. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от safsad on 08-Окт-16, 02:32
	С офф. компилятором Go крос-компиляция проще некуда. На любой системе заходишь в директорию и через make.all (или build.all) собираешь что нужно, указывая OS и архитектуру.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	52. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Аноним (??) on 09-Окт-16, 12:38
	в слове официальный только одна Ф…
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	10. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 03:52
	Он для армов и не рассчитан вроде как. deck was built with two assumptions: 1. modern hardware is fast: [...] On my old Sandy Bridge Core i5 laptop with an oldish SSD drive hashing the full system (~4gb) takes about a minute. 2. storage is cheap. you can keep a backup copy of every file and restore it if it was modified
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	19. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от pampa (ok) on 08-Окт-16, 12:23
	> Он для армов и не рассчитан вроде как. > deck was built with two assumptions: > 1. modern hardware is fast: [...] On my old Sandy Bridge Core > i5 laptop with an oldish SSD drive hashing the full system > (~4gb) takes about a minute. > 2. storage is cheap. you can keep a backup copy of every > file and restore it if it was modified Можно собрать и под АРМ, но насколько приемлимо будет работать на какой-нить RPi с SD-шкой вместо диска непонятно.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	23. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Michael Shigorin (ok) on 08-Окт-16, 13:19
	> deck was built with two assumptions: Автор хоть сравнивает его с давно существующим checkinstall, который был создан явно без таких предположений?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	26. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от pampa (ok) on 08-Окт-16, 13:39
	>> deck was built with two assumptions: > Автор хоть сравнивает его с давно существующим checkinstall, который был создан явно > без таких предположений? (я автор) checkinstall использует LD_PRELOAD для перехвата системных вызовов. Если coreutils собрать статически, или использовать вместо них статический бизибокс, то LD_PRELOAD работать не будет. У меня была задача сделать как можно проще и без каких-либо предположений об окружении (кроме чтого, что оно может запустить бинарник). Чтобы можно было например загрузить голое ядро с бизибоксом, бросить туда бинарник и оно заработало. Сканировать все файлы и считать хеши неэффективно, но зато надежно. Ну и когда собираешь линукс по частям из исходников, тут не до эффективности :)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	43. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Аноним (??) on 08-Окт-16, 23:17
	Возможно, вам как автору будет интересно мнение пользователя LFS. Сижу на LFS с 2006 года, практически сразу (в 2006) почувствовал необходимость в а. сохранении информации о том, каким образом и с какими configure-флагами был собран софт, и б. пакетном менеджере для хранения списка фалов каждого установленного пакета. Недостаток checkinstall/paco и подобных в том, что пакет собирается от рута (и уже на этапе сборки может поломать систему, пусть даже не системные файлы обновить, а просто какой-нибудь процесс прибить) и что список изменённых файлов мы узнаём лишь после установки, так что может потребоваться уйма времени на восстановление из бэкапов. Сам долго пользовался paco, но однажды паранойя одержала верх, и пересел на Slackware pkgtools (когда пакет ставится в DESTDIR и лишь потом переносится на основную систему). Сейчас использую самописный аналог, который собирает от непривилегированного пользователя и перед установкой показывает, какие файлы будут перезатёрты, какие добавлены и т.д., что очень удобно. Ну и, как по мне, держать в LFS-системе go-компилятор лишь для пакетного менеджера перебор.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	44. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от pampa (ok) on 08-Окт-16, 23:35
	>[оверквотинг удален] > файлы обновить, а просто какой-нибудь процесс прибить) и что список изменённых > файлов мы узнаём лишь после установки, так что может потребоваться уйма > времени на восстановление из бэкапов. > Сам долго пользовался paco, но однажды паранойя одержала верх, и пересел на > Slackware pkgtools (когда пакет ставится в DESTDIR и лишь потом переносится > на основную систему). Сейчас использую самописный аналог, который собирает от непривилегированного > пользователя и перед установкой показывает, какие файлы будут перезатёрты, какие добавлены > и т.д., что очень удобно. > Ну и, как по мне, держать в LFS-системе go-компилятор лишь для пакетного > менеджера перебор. У меня были примерно те-же проблемы, но собирать все в DESTDIR я так и не осилил. Не все пакеты умеют DESTDIR, некоторым после установки в DESTDIR нужно писать postinstall скрипты etc. Работы на порядок больше чем сборка и установка от рута по-живому. Проблему поломки при установке я решаю откатом на предыдущее состояние. Т.к. пакетный менеджер собран статически, он не ломается. На совсем крайний случай могу загрузиться в статический-же busybox и откатить поломку из него. Особой паранои не испытываю, т.к. у меня всегда храниться контрольная сумма и бэкап всех файлов системы, и я после каждой установки знаю что и как поменялось. Восстановить файлы я могу выборочно поштучно, если вижу, что make install сделал что-то странное. Что до Go компилятора - достаточно распаковать официальный бинарный релиз в /opt и прописать несколько переменных окружения.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	53. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от Аноним (??) on 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++.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	58. "Первый выпуск пакетного менеджера Deck"	–1 +/–
	Сообщение от Michael Shigorin (ok) on 10-Окт-16, 15:48
	> Сам долго пользовался paco, но однажды паранойя одержала верх, и пересел на > Slackware pkgtools (когда пакет ставится в DESTDIR и лишь потом переносится > на основную систему). Сейчас использую самописный аналог, который собирает от > непривилегированного пользователя и перед установкой показывает, какие файлы > будут перезатёрты, какие добавлены и т.д., что очень удобно. Возможно, покажется интересным: http://ftp.altlinux.org/pub/people/ldv/hasher/
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

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

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

	47. "Первый выпуск пакетного менеджера Deck"	+2 +/–
	Сообщение от angra (ok) on 09-Окт-16, 00:19
	> SSD drive > storage is cheap Взаимоисключающие параграфы во всей красе.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	30. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от pampa (ok) on 08-Окт-16, 14:03
	> плин подумал уже посмотреть эту хреновину для своих ARM-поделок, > ага прям ЩАЗ я буду тащить go только радо этого Я могу собрать релиз под арм. У меня где-то валялась RPi, надо поискать.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Первый выпуск пакетного менеджера Deck"	+2 +/–
Сообщение от uchiya (ok) on 08-Окт-16, 00:36
>> deck обеспечивает вычисление и хранение контрольных сумм и резервных копий для каждого системного файла >> отслеживает изменения в файловой системе, связанные с установкой программ, давая возможность затем удалить установленные файлы угу, linux-base и linux-devel это 100+ пакетов, к завтрашнему школьному дню как-раз закончу комитить каждый пакет, мечта сбылась.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Первый выпуск пакетного менеджера Deck"	+10 +/–
Сообщение от modos189 (ok) on 08-Окт-16, 01:37
Помню, данным давно, когда в Windows XP трава была зеленее, а небо синее, я открыл для себя какую-то утилиту, которую, предполагалось, я должен запускать до и после установки других программ, и эта утилита запоминала список новых файлов и ключей реестра, чтобы позже я мог полностью удалить все следы нужной программы, не оставляя кучи говна по всей системе. Естесно, я не в такой степени долбанутый, чтобы для установки каждой малейшей программки ждать по 10 минут полного сканирования системы, поэтому запускал сканирование только для больших программ, которые точно засрут по всей системе. А потом я узнал, что в линукс системах программки лежат в пакетах, а менеджеры управления пакетов умеют не только установить эти программки, но и удалить безвозвратно все упоминания.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Первый выпуск пакетного менеджера Deck"	+3 +/–
	Сообщение от Crazy Alex (ok) on 08-Окт-16, 02:15
	Там были ещё более "волшебные" утилиты, которые как-то умудрялись делать диск "временно изменяемым" - то есть ставишь софтину, указываешь, какие диски контролировать, дальше всё, что пишешь на них, живёт ровно до перезагрузки - после ребута всё как было. Надо что-то поменять - запускаешь гуй софтины, вводишь пароль, жмешь "Accept changes" или что-то подобное. Для компьютерного клуба - удобная хреновина была. Причём ни тормозов от неё, ни побочек... До сих пор гадаю, как работала. Кстати, более продвинутые "анинсталлеры" чем упомянутый сами следили, что изменяется - просто тыкаешь ему "сейчас буду что-то устанавливать", ставишь, тыкаешь "я закончил, запоминай" - у тебя имя спрашивает, и готово. Эх, сколько извратов придумано для борьбы с виндовым бардаком было...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	39. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от gresolio (ok) on 08-Окт-16, 16:15
	Из таких программ мне в своё время запомнилась Deep Freeze https://ru.wikipedia.org/wiki/Deep_Freeze Полезно не только для компьютерных клубов, но и вообще для любых публичных компов, например школьный компьютерный класс, аудитории в универе, etc... Принцип действия достаточно простой, и чем то напоминает современные overlay-filesystem. Программа по сути является драйвером работающим на уровне ядра, который защищает целостность данных жёсткого диска путём перенаправления операций записи, получаются аля "виртуальные изменения" которые при ребуте очищаются. Главное на компе запаролить BIOS, запретить загрузку из других устройств, и желательно даже хорошенько закрыть системник, потому что если будет доступ до железа из под другой ОС, скажем Live CD или USB, то всё - программа заморозки уже ничем не поможет.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Аноним (??) on 08-Окт-16, 04:07
	> А потом я узнал, что в линукс системах программки лежат в пакетах, а менеджеры управления пакетов умеют не только установить эти программки, но и удалить безвозвратно все упоминания. Логи созданные в ходе использования программы останутся, их же менеджеры пакетов не могут достать. ArtMoney...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	12. "Первый выпуск пакетного менеджера Deck"	–4 +/–
	Сообщение от soarin (ok) on 08-Окт-16, 04:41
	Чисти-чисти :D http://askubuntu.com/questions/45535/how-do-i-clean-up-my-dc... В линуксах тоже какбэ нормально остаётся много чего. Естественно зависит от софта. Как-то было дело ставил Wine в той же Ubuntu, так потом после удаления осталось куча призраков в различных менюшках. Пришлось ручками выковыривать.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	24. "Первый выпуск пакетного менеджера Deck"	–1 +/–
	Сообщение от Michael Shigorin (ok) on 08-Окт-16, 13:22
	> Как-то было дело ставил Wine в той же Ubuntu Вот туда и вешайте баг.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	64. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Аноним (??) on 11-Окт-16, 10:02
	Если считать что uninstall-ер программы должен всё сам подчищать, то какой смысл в данной функции пакетника :) p.s. Человек просто привёл пример, опровергающий высказывание о идеальности пакетников в некоторых системах.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	13. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от soarin (ok) on 08-Окт-16, 04:50
	А приницип программ "Мой $HOME - куда хочу, туда и ..." так вообще задалбливает. Чамтенько не могут обойтись парой папок (не мамок) типа ~/.local ~/.cache, обязательно надо свою создать.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	14. "Первый выпуск пакетного менеджера Deck"	+2 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 08:31
	Большинство софта в Линухе вообще XDG не соблюдает, так что о чём тут говорить... Бардак в стандартах, хотя стандарт вроде как есть, но все воротят как хотят.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	18. "Первый выпуск пакетного менеджера Deck"	+2 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 11:34
	> Большинство софта в Линухе вообще XDG не соблюдает, так что о чём > тут говорить... Бардак в стандартах, хотя стандарт вроде как есть, но > все воротят как хотят. сейчас как раз наоборот, модно не linuxway стандарты делать, а пытаться вставить разные вендорлокd
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Первый выпуск пакетного менеджера Deck"	–1 +/–
	Сообщение от mumu (ok) on 08-Окт-16, 10:21
	> чтобы для установки каждой малейшей программки ждать по 10 минут полного сканирования А перехватывать вызовы и смотреть только те файлы, к которым программа обращается на запись та утилита не умела? Русинович показывал как это делать на примере еще -цать лет назад. Я использовал похожее на те программы, которые были полнофункциональными лишь на время триала. Всё вполне работало без всяких "полных сканирований системы"
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

15. "Первый выпуск пакетного менеджера Deck"	+/–
Сообщение от hoopoe (ok) on 08-Окт-16, 10:20
а если одно и то-же файло изменялось двумя-тремя пакетами, то откат к какой версии будет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от f2404 (ok) on 08-Окт-16, 10:28
	Видимо, там хранятся все версии файлов, как в гите. Это значит, что объём служебных данных этого менеджера будет постоянно расти при установке пакетов.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	21. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от pampa (ok) on 08-Окт-16, 12:37
	> а если одно и то-же файло изменялось двумя-тремя пакетами, то откат к > какой версии будет? Храница последяя закомиченая версия файла. По хорошему, пакеты не должны наступать на файлы друг друга, но при сборке LFS такое происодит - kill есть в нескольких пакетах, дублирущие маны в man-pages и coreutils итд. Если пакет при установке поменял чужой файл, утилита покажет что файл был модифицирован. В этом случае можно откатить изменение, либо закомитить и тогда файл перейдет в другой пакет.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	25. "Первый выпуск пакетного менеджера Deck"	–1 +/–
	Сообщение от Аноним (??) on 08-Окт-16, 13:37
	> пакеты не должны наступать на файлы друг друга Тогда этот Desk не нужен. Совсем. > файл был модифицирован. В этом случае можно откатить изменение, либо закомитить Пользователь фигея от такого количества предложений начнет жать куда попало(или он спец по внутренностям?) и убъет систему.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	27. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от pampa (ok) on 08-Окт-16, 13:46
	>> пакеты не должны наступать на файлы друг друга > Тогда этот Desk не нужен. Совсем. >> файл был модифицирован. В этом случае можно откатить изменение, либо закомитить > Пользователь фигея от такого количества предложений начнет жать куда попало(или он спец > по внутренностям?) и убъет систему. Тулза для тех кто собирает систему из исходников, Linux From Scratch, или производные. Это уже как бы не совсем простой пользователь, и разобраться во внутренностях это одна из причин, почему он это делает. LFS не предполагает вообще никакого менеджмента пакетов, а deck можно просто бросить в систему сразу после сборки промежуточного тулчейна и начать использовать без внесения каких-либо изменений в процесс, описанный в книге. И получить рудиментарный менеджмент пакетов и инсайт какой пакет что и куда пихает.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Аноним (??) on 08-Окт-16, 13:51
	> разобраться во внутренностях это одна из причин, почему он это делает Разве что. Правда, уверен, что при этом будет не много возможности нагадить себе только по причине "неуловимого Джона", т.к. авторы софта в той или иной мере прямо или косвенно воспитаны нормальными пакетными менеджерами.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	29. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от pampa (ok) on 08-Окт-16, 14:00
	>> разобраться во внутренностях это одна из причин, почему он это делает > Разве что. > Правда, уверен, что при этом будет не много возможности нагадить себе только > по причине "неуловимого Джона", т.к. авторы софта в той или иной > мере прямо или косвенно воспитаны нормальными пакетными менеджерами. Большинство воспитаны, но есть и проблемные пакеты, которые не понимают PREFIX и DESTDIR, или понимают, но делают все по своему. Тот же апач, если собирать ./configure --prefix=/usr && make && make install насоздает кучу левых директорий в /usr. С такими пакетами кмк мейнтейнеры забили на отправку фиксов апстрим и просто доводят напильником на местах.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

40. "Первый выпуск пакетного менеджера Deck"	+/–
Сообщение от Аноним (??) on 08-Окт-16, 17:47
RPM отслеживает изменения.. и дает удалить файлы. Ээ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Первый выпуск пакетного менеджера Deck"	–1 +/–
Сообщение от Kroz (ok) on 08-Окт-16, 19:42
Они изобрели emerge?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	49. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от Ergil (ok) on 09-Окт-16, 02:11
	Скорее emerde. Был такой порт emerge для Слаки, назывался emerde, вот ключевым в нем было французское слово merde, да. В один прекрасный день, году так в 2003, оно превратило мою слаку в Gentoo, при загрузке сначала шли слаковские иниты, а потом гентушные, пришлось убить старушку, что бы не мучалась и поставить Gentoo в чистую, забыв об ужасах слаки не имеющей пакетного менеджера. Вот они тоже пытаются натянуть хоть что-то на убожество LFS.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	56. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Michael Shigorin (ok) on 10-Окт-16, 15:44
	> Вот они тоже пытаются натянуть хоть что-то на убожество LFS. Скорее сделать из LFS что-то совсем другое...
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	59. "Первый выпуск пакетного менеджера Deck"	+1 +/–
	Сообщение от Ergil (ok) on 10-Окт-16, 15:53
	>> Вот они тоже пытаются натянуть хоть что-то на убожество LFS. > Скорее сделать из LFS что-то совсем другое... Ну что бы сделать из LFS что-то совсем другое можно в него притащить нормальный пакетный менеджер. А тут хотят сохранить убогость LFS'а, а сверху натянуть сову на глобус. Мне кажется, что уж проще btrfsные снапшоты натянуть на LFS, перед make install делать снапшот, что бы можно было фарш провернуть назад. Но суровые любители секса на лыжах в гамаке не ищут легких путей.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	66. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Аноним (??) on 11-Окт-16, 19:38
	Они изобрели aufs. А что до emerge, то он не умеет восстанавливать пред. версии файликов. Да и шалости eselect не помнит.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

50. "Первый выпуск пакетного менеджера Deck"	–1 +/–
Сообщение от tty (??) on 09-Окт-16, 04:39
>держать в LFS-системе go-компилятор лишь для пакетного менеджера вот именно ГО это мракобесие старого маразматика, ересь не нужна когда есть православный Си нуи питон и ява
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	51. "Первый выпуск пакетного менеджера Deck"	–1 +/–
	Сообщение от Аноним (??) on 09-Окт-16, 11:57
	Ну да, Ява - это и не православно, и не феншуйно, и противоречит гиковскому духу.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	54. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Crazy Alex (ok) on 09-Окт-16, 22:59
	Вот как раз питон на го заменить - самое оно. Порог вхождения примерно одинаковый, простота писанины - тоже. На выходе - хороший контроль типов, лучшее быстродействие и управление зависимостями - хоть своё, а не системное, но из коробки и без чудес.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

55. "Первый выпуск пакетного менеджера Deck"	+1 +/–
Сообщение от Вареник on 10-Окт-16, 05:42
Больше несовместимых форматов, хороших и разных!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

60. "Первый выпуск пакетного менеджера Deck"	–2 +/–
Сообщение от Аноним (??) on 10-Окт-16, 16:07
Когда-то я задался вопросом, как отлаживать Bash скрипты так, чтобы можно было попробовать запустить на реальной ФС, но потом при возможности откатить (тоже при сборке LFS). Приходило на ум что-то вроде специальной ФС на уровне ядра: основная ФС - readonly, а изменения сохраняются в отдельный overlay. Откатиться легко, дропнув overlay. Если всё норм - изменения в overlay применяются к основной ФС. <наркомания> Ещё возникает мысль - а не положить ли всю ФС под контроль git и сделать git системным пакетным менеджером тогда уж? (git не принципиален, можно взять другую СКВ). Нужно удалить пакет? - удаляется его коммит, а все, установленные после него, - rebase. Если у пакета зависимости, то для него создаётся коммит как мерж всех коммитов-зависимостей + изменения самого пакета. Нужно удалить пакет, от которого зависят другие, вместе с зависимостями? - делаем rebase, удяляя пакет и его зависимости. </наркомания>
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Первый выпуск пакетного менеджера Deck"	–1 +/–
	Сообщение от pampa (ok) on 10-Окт-16, 16:45
	> <наркомания> > Ещё возникает мысль - а не положить ли всю ФС под контроль > git и сделать git системным пакетным менеджером тогда уж? (git не > принципиален, можно взять другую СКВ). > Нужно удалить пакет? - удаляется его коммит, а все, установленные после него, > - rebase. > </наркомания> это было самое первое что я попробовал. Но гит а) плохо работает с бинарниками б) при ребейсе или reset --hard сначала удаляет все дерево, потом линкует его обратно. Соответственно при удалиении всех либ и бинарников система накрывается.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	63. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Michael Shigorin (ok) on 10-Окт-16, 21:50
	> это было самое первое что я попробовал. Но гит а) плохо работает > с бинарниками б) при ребейсе или reset --hard сначала удаляет все > дерево, потом линкует его обратно. Соответственно при удалиении всех либ и > бинарников система накрывается. Как днём подумал вслух коллега -- возможно, написать свой git-reset было бы проще.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	65. "Первый выпуск пакетного менеджера Deck"	+/–
	Сообщение от Andrey Mitrofanov on 11-Окт-16, 10:46
	>> это было самое первое что я попробовал. Но гит а) плохо работает >> с бинарниками б) при ребейсе или reset --hard сначала удаляет все > Как днём подумал вслух коллега -- возможно, написать свой git-reset было бы > проще. А для эффективности checkout-ов и коммитов облепить это всё симлик-фармингом, поколениями профилей програм/узеров и системы, гарбидж-коллектором, поставить диск побольше (не сжимать и без git-а)...  Подсказать, |-) где это уже можно посмотреть?
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

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

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