The OpenNET Project / Index page

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

Первый выпуск пакетного менеджера Deck

07.10.2016 23:49

Сформирован первый выпуск проекта Deck, в рамках которого развивается простой пакетный менеджер для дистрибутивов, практикующих установку программ из исходных текстов, таких как Linux From Scratch. Deck не манипулирует пакетами как таковыми, а отслеживает изменения в файловой системе, связанные с установкой программ, давая возможность затем удалить установленные файлы и восстановить состояние изменённых в процессе установки файлов.

Deck предоставляет пользователю три базовые команды: "deck scan", "deck commit" и "deck uninstall". Первая команда используется для определения файлов, установленных, удалённых или изменённых по сравнению с прошлым состоянием ФС. Если запустить "deck scan" до и после установки программы из исходных текстов, утилита сформирует список изменений. Команда "deck commit" позволяет запомнить выявленные изменения и связать их с установленным приложением. В дальнейшем для удаления этого приложения можно воспользоваться командой "deck uninstall".

Для реализации данной функциональности deck обеспечивает вычисление и хранение контрольных сумм и резервных копий для каждого системного файла. Утилита написана на языке Go и распространяется как общественное достояние.

  1. Главная ссылка к новости (https://github.com/pampa/deck/...)
  2. OpenNews: Выпуск пакетного менеджера Apt 1.3
  3. OpenNews: Доступен пакетный менеджер GNU Guix 0.11 и дистрибутив GuixSD на его основе
  4. OpenNews: Вышел дистрибутив NixOS 16.09, использующий пакетный менеджер Nix
  5. OpenNews: Пакетный менеджер DNF будет переработан на языке Си
  6. OpenNews: Выпуск пакетного менеджера Pacman 5.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45289-packet
Ключевые слова: packet, deck
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (62) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:54, 07/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    О — Общественное достояние.
     
  • 1.2, олхнтп (?), 00:26, 08/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    плин подумал уже посмотреть эту хреновину для своих ARM-поделок,
    ага прям ЩАЗ я буду тащить go только радо этого
     
     
  • 2.6, Vee Nee (?), 01:40, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Это же не питон. Зачем тащить Go, когда тащить нужно только результат его компиляции?
     
     
  • 3.20, Stax (ok), 12:37, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений и обновляемые библиотеки с привязками, а также маленькие, легко обновляемые приложения, когда go скомпилит вам КАЖДЫЙ бинарник в 20-мегабайтную хрень, каждую из которых придется обновлять целиком при необходимости обновить как приложение, так и библиотеку (из-за уязвимости, например). Это ведь именно то, что нужно для вашего ARM!
     
     
  • 4.22, pampa (ok), 12:41, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений

    Питон нельзя собрать в один статический бинарник и бросить на голую систему и ядра и бизибокса

     
     
  • 5.33, Аноним (-), 14:42, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений
    > Питон нельзя собрать в один статический бинарник

    Да что вы говорите!
    https://wiki.python.org/moin/BuildStatically

     
     
  • 6.34, pampa (ok), 14:49, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>> Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений
    >> Питон нельзя собрать в один статический бинарник
    > Да что вы говорите!
    > https://wiki.python.org/moin/BuildStatically

    А теперь расскажите, как мне в этот-же бинарник засунуть питоновские либы и приложение на питоне.

     
     
  • 7.35, Аноним (-), 14:56, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Рецепт: берем 500 мегабайтный пакет питона (вместе со всем зависимости) и исполняемый файл приложения и пакуем всё в инсталлятор.
     
     
  • 8.38, Аноним (-), 15:08, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    О, вот и диванный теоретик подтянулся Расскажи нам, как ты умудряешся собрать п... текст свёрнут, показать
     
  • 7.37, Аноним (-), 15:06, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >>>> Конечно, зачем иметь модульный питон, пригодный для кучи разных приложений
    >>> Питон нельзя собрать в один статический бинарник
    >> Да что вы говорите!
    >> https://wiki.python.org/moin/BuildStatically
    > А теперь расскажите, как мне в этот-же бинарник засунуть питоновские либы

    Прилинковать, не?
    > и приложение на питоне.

    Приложения на питоне, внезапно, совсем не бинарник.


     
  • 4.32, Аноним (-), 14:41, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вы описали крайнюю ситуацию. Либы GO можно прилинковать к исполняемому необновляемому файлу. А весь функциональный код приложения вынести в маленький подключаемый модуль, который и будет обновляться.
     
     
  • 5.42, Stax (ok), 23:13, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Я описал то, что вижу в жизни. Почему-то 99% кода на go собирают вот так:
    $ ll /usr/bin/kubectl
    -rwxr-xr-x. 2 root root 46M июл 17 15:04 /usr/bin/kubectl

    Исключения, возможно, бывают. Но ВСЕ вокруг поголовно собирают именно так. Любые приложения на go, самых разных мастей. Видимо, "так принято". Понимаю, что можно иначе - но иначе, видимо, "не принято". Вот и все...

     
  • 3.31, Аноним (-), 14:33, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сanonical тащат 500 метров питона, они дураки?
     
     
  • 4.36, Аноним (-), 15:02, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Сanonical тащат 500 метров питона, они дураки?

    Мне вот интересно, откуда они (или некоторые воинствующие анонимы) берут эти волшебные 500 метров? Ведь не первый раз на опеннете вижу.

    Я например полюбопытсвовал – и оказалось, что в репах под две тысячи питоно-пакетов (для второго питона), которые занимают в сумме 272 мб (причем, тот же рейнджер считается питонопакетом). А сам пакет с вторым питоном занимает у меня ~66мб (с третим - 79мб).

    Правда, у меня не каноникал, но все равно, маленькой репу (вернее, количество софта в ней) назвать нелься.

     
     
  • 5.45, angra (ok), 00:11, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, ты смотришь на размер пакета, а не на результат его разворачивания. Умножь на 2
    Во-вторых, ты почему-то игнорируешь третий питон, а так как программ на питоне может быть нужно значительно больше одной, то есть высокая вероятность, что понадобятся обе ветки питона. Умножь еще на 2.

     
     
  • 6.48, Аноним (-), 01:09, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Во-первых, ты смотришь на размер пакета, а не на результат его разворачивания.

    Неа. Любой мал-мальский пакетник показывает "Installed Size".

    > понадобятся обе ветки питона. Умножь еще на 2.

    И даже так 500 мб никак не набираются.

     
  • 2.9, safsad (?), 02:32, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    С офф. компилятором Go крос-компиляция проще некуда. На любой системе заходишь в директорию и через make.all (или build.all) собираешь что нужно, указывая OS и архитектуру.
     
     
  • 3.52, Аноним (-), 12:38, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    в слове [b]официальный[/b] только одна Ф…
     
  • 2.10, Аноним (-), 03:52, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Он для армов и не рассчитан вроде как.

    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

     
     
  • 3.19, pampa (ok), 12:23, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Он для армов и не рассчитан вроде как.
    > 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-шкой вместо диска непонятно.

     
  • 3.23, Michael Shigorin (ok), 13:19, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > deck was built with two assumptions:

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

     
     
  • 4.26, pampa (ok), 13:39, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> deck was built with two assumptions:
    > Автор хоть сравнивает его с давно существующим checkinstall, который был создан явно
    > без таких предположений?

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

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

     
     
  • 5.43, Аноним (-), 23:17, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, вам как автору будет интересно мнение пользователя LFS Сижу на LFS с ... большой текст свёрнут, показать
     
     
  • 6.44, pampa (ok), 23:35, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > файлы обновить, а просто какой-нибудь процесс прибить) и что список изменённых
    > файлов мы узнаём лишь после установки, так что может потребоваться уйма
    > времени на восстановление из бэкапов.
    > Сам долго пользовался paco, но однажды паранойя одержала верх, и пересел на
    > Slackware pkgtools (когда пакет ставится в DESTDIR и лишь потом переносится
    > на основную систему). Сейчас использую самописный аналог, который собирает от непривилегированного
    > пользователя и перед установкой показывает, какие файлы будут перезатёрты, какие добавлены
    > и т.д., что очень удобно.
    > Ну и, как по мне, держать в LFS-системе go-компилятор лишь для пакетного
    > менеджера перебор.

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

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

     
     
  • 7.53, Аноним (-), 13:59, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Из 4 сотен установленных у меня пакетов DESTDIR не поддерживается, наверное, в 7... большой текст свёрнут, показать
     
  • 6.58, Michael Shigorin (ok), 15:48, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Сам долго пользовался paco, но однажды паранойя одержала верх, и пересел на
    > Slackware pkgtools (когда пакет ставится в DESTDIR и лишь потом переносится
    > на основную систему). Сейчас использую самописный аналог, который собирает от
    > непривилегированного пользователя и перед установкой показывает, какие файлы
    > будут перезатёрты, какие добавлены и т.д., что очень удобно.

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

     
  • 5.46, angra (ok), 00:18, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Сканировать все файлы и считать хеши неэффективно, но зато надежно.

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

     
  • 5.57, Michael Shigorin (ok), 15:47, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>> deck was built with two assumptions:
    >> Автор хоть сравнивает его с давно существующим checkinstall, который был создан явно
    >> без таких предположений?
    > У меня была задача сделать как можно проще и без каких-либо предположений об окружении
    > (кроме чтого, что оно может запустить бинарник). Чтобы можно было например загрузить
    > голое ядро с бизибоксом, бросить туда бинарник и оно заработало.

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

     
  • 3.47, angra (ok), 00:19, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > SSD drive
    > storage is cheap

    Взаимоисключающие параграфы во всей красе.


     
  • 2.30, pampa (ok), 14:03, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > плин подумал уже посмотреть эту хреновину для своих ARM-поделок,
    > ага прям ЩАЗ я буду тащить go только радо этого

    Я могу собрать релиз под арм. У меня где-то валялась RPi, надо поискать.

     

  • 1.4, uchiya (ok), 00:36, 08/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >> deck обеспечивает вычисление и хранение контрольных сумм и резервных копий для каждого системного файла
    >> отслеживает изменения в файловой системе, связанные с установкой программ, давая возможность затем удалить установленные файлы

    угу, linux-base и linux-devel это 100+ пакетов, к завтрашнему школьному дню как-раз закончу комитить каждый пакет, мечта сбылась.

     
  • 1.5, modos189 (ok), 01:37, 08/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Помню, данным давно, когда в Windows XP трава была зеленее, а небо синее, я открыл для себя какую-то утилиту, которую, предполагалось, я должен запускать до и после установки других программ, и эта утилита запоминала список новых файлов и ключей реестра, чтобы позже я мог полностью удалить все следы нужной программы, не оставляя кучи говна по всей системе.
    Естесно, я не в такой степени долбанутый, чтобы для установки каждой малейшей программки ждать по 10 минут полного сканирования системы, поэтому запускал сканирование только для больших программ, которые точно засрут по всей системе.

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

     
     
  • 2.8, Crazy Alex (ok), 02:15, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Там были ещё более "волшебные" утилиты, которые как-то умудрялись делать диск "временно изменяемым" - то есть ставишь софтину, указываешь, какие диски контролировать, дальше всё, что пишешь на них, живёт ровно до перезагрузки - после ребута всё как было. Надо что-то поменять - запускаешь гуй софтины, вводишь пароль, жмешь "Accept changes" или что-то подобное. Для компьютерного клуба - удобная хреновина была. Причём ни тормозов от неё, ни побочек... До сих пор гадаю, как работала.

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

    Эх, сколько извратов придумано для борьбы с виндовым бардаком было...

     
     
  • 3.39, gresolio (ok), 16:15, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Из таких программ мне в своё время запомнилась Deep Freeze https://ru.wikipedia.org/wiki/Deep_Freeze
    Полезно не только для компьютерных клубов, но и вообще для любых публичных компов, например школьный компьютерный класс, аудитории в универе, etc... Принцип действия достаточно простой, и чем то напоминает современные overlay-filesystem. Программа по сути является драйвером работающим на уровне ядра, который защищает целостность данных жёсткого диска путём перенаправления операций записи, получаются аля "виртуальные изменения" которые при ребуте очищаются. Главное на компе запаролить BIOS, запретить загрузку из других устройств, и желательно даже хорошенько закрыть системник, потому что если будет доступ до железа из под другой ОС, скажем Live CD или USB, то всё - программа заморозки уже ничем не поможет.
     
  • 2.11, Аноним (-), 04:07, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А потом я узнал, что в линукс системах программки лежат в пакетах, а менеджеры управления пакетов умеют не только установить эти программки, но и удалить безвозвратно все упоминания.

    Логи созданные в ходе использования программы останутся, их же менеджеры пакетов не могут достать.

    ArtMoney...

     
  • 2.12, soarin (ok), 04:41, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Чисти-чисти :D
    http://askubuntu.com/questions/45535/how-do-i-clean-up-my-dconf-database

    В линуксах тоже какбэ нормально остаётся много чего. Естественно зависит от софта.
    Как-то было дело ставил Wine в той же Ubuntu, так потом после удаления осталось куча призраков в различных менюшках. Пришлось ручками выковыривать.

     
     
  • 3.24, Michael Shigorin (ok), 13:22, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Как-то было дело ставил Wine в той же Ubuntu

    Вот туда и вешайте баг.

     
     
  • 4.64, Аноним (-), 10:02, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если считать что uninstall-ер программы должен всё сам подчищать, то какой смысл в данной функции пакетника :)

    p.s. Человек просто привёл пример, опровергающий высказывание о идеальности пакетников в некоторых системах.

     
  • 2.13, soarin (ok), 04:50, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А приницип программ "Мой $HOME - куда хочу, туда и ..." так вообще задалбливает.
    Чамтенько не могут обойтись парой папок (не мамок) типа ~/.local ~/.cache, обязательно надо свою создать.
     
     
  • 3.14, Аноним (-), 08:31, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Большинство софта в Линухе вообще XDG не соблюдает, так что о чём тут говорить... Бардак в стандартах, хотя стандарт вроде как есть, но все воротят как хотят.
     
     
  • 4.18, Аноним (-), 11:34, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Большинство софта в Линухе вообще XDG не соблюдает, так что о чём
    > тут говорить... Бардак в стандартах, хотя стандарт вроде как есть, но
    > все воротят как хотят.

    сейчас как раз наоборот,
    модно не linuxway стандарты делать, а пытаться вставить разные вендорлокd

     
  • 2.16, mumu (ok), 10:21, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > чтобы для установки каждой малейшей программки ждать по 10 минут полного сканирования

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

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

     

  • 1.15, hoopoe (ok), 10:20, 08/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а если одно и то-же файло изменялось двумя-тремя пакетами, то откат к какой версии будет?
     
     
  • 2.17, f2404 (ok), 10:28, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо, там хранятся все версии файлов, как в гите. Это значит, что объём служебных данных этого менеджера будет постоянно расти при установке пакетов.
     
  • 2.21, pampa (ok), 12:37, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > а если одно и то-же файло изменялось двумя-тремя пакетами, то откат к
    > какой версии будет?

    Храница последяя закомиченая версия файла. По хорошему, пакеты не должны наступать на файлы друг друга, но при сборке LFS такое происодит - kill есть в нескольких пакетах, дублирущие маны в man-pages и coreutils итд. Если пакет при установке поменял чужой файл, утилита покажет что файл был модифицирован. В этом случае можно откатить изменение, либо закомитить и тогда файл перейдет в другой пакет.

     
     
  • 3.25, Аноним (-), 13:37, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > пакеты не должны наступать на файлы друг друга

    Тогда этот Desk не нужен. Совсем.

    > файл был модифицирован. В этом случае можно откатить изменение, либо закомитить

    Пользователь фигея от такого количества предложений начнет жать куда попало(или он спец по внутренностям?) и убъет систему.

     
     
  • 4.27, pampa (ok), 13:46, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> пакеты не должны наступать на файлы друг друга
    > Тогда этот Desk не нужен. Совсем.
    >> файл был модифицирован. В этом случае можно откатить изменение, либо закомитить
    > Пользователь фигея от такого количества предложений начнет жать куда попало(или он спец
    > по внутренностям?) и убъет систему.

    Тулза для тех кто собирает систему из исходников, Linux From Scratch, или производные.
    Это уже как бы не совсем простой пользователь, и разобраться во внутренностях это одна из причин, почему он это делает. LFS не предполагает вообще никакого менеджмента пакетов, а deck можно просто бросить в систему сразу после сборки промежуточного тулчейна и начать использовать без внесения каких-либо изменений в процесс, описанный в книге. И получить рудиментарный менеджмент пакетов и инсайт какой пакет что и куда пихает.

     
     
  • 5.28, Аноним (-), 13:51, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > разобраться во внутренностях это одна из причин, почему он это делает

    Разве что.

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

     
     
  • 6.29, pampa (ok), 14:00, 08/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> разобраться во внутренностях это одна из причин, почему он это делает
    > Разве что.
    > Правда, уверен, что при этом будет не много возможности нагадить себе только
    > по причине "неуловимого Джона", т.к. авторы софта в той или иной
    > мере прямо или косвенно воспитаны нормальными пакетными менеджерами.

    Большинство воспитаны, но есть и проблемные пакеты, которые не понимают PREFIX и DESTDIR, или понимают, но делают все по своему. Тот же апач, если собирать ./configure --prefix=/usr && make && make install насоздает кучу левых директорий в /usr. С такими пакетами кмк мейнтейнеры забили на отправку фиксов апстрим и просто доводят напильником на местах.

     

  • 1.40, Аноним (-), 17:47, 08/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    RPM отслеживает изменения.. и дает удалить файлы. Ээ?
     
  • 1.41, Kroz (ok), 19:42, 08/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Они изобрели emerge?
     
     
  • 2.49, Ergil (ok), 02:11, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скорее emerde. Был такой порт emerge для Слаки, назывался emerde, вот ключевым в нем было французское слово merde, да. В один прекрасный день, году так в 2003, оно превратило мою слаку в Gentoo, при загрузке сначала шли слаковские иниты, а потом гентушные, пришлось убить старушку, что бы не мучалась и поставить Gentoo в чистую, забыв об ужасах слаки не имеющей пакетного менеджера.
    Вот они тоже пытаются натянуть хоть что-то на убожество LFS.
     
     
  • 3.56, Michael Shigorin (ok), 15:44, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот они тоже пытаются натянуть хоть что-то на убожество LFS.

    Скорее сделать из LFS что-то совсем другое...

     
     
  • 4.59, Ergil (ok), 15:53, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Вот они тоже пытаются натянуть хоть что-то на убожество LFS.
    > Скорее сделать из LFS что-то совсем другое...

    Ну что бы сделать из LFS что-то совсем другое можно в него притащить нормальный пакетный менеджер. А тут хотят сохранить убогость LFS'а, а сверху натянуть сову на глобус. Мне кажется, что уж проще btrfsные снапшоты натянуть на LFS, перед make install делать снапшот, что бы можно было фарш провернуть назад. Но суровые любители секса на лыжах в гамаке не ищут легких путей.

     
  • 2.66, Аноним (-), 19:38, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Они изобрели aufs.
    А что до emerge, то он не умеет восстанавливать пред. версии файликов. Да и шалости eselect не помнит.
     

  • 1.50, tty (??), 04:39, 09/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >держать в LFS-системе go-компилятор лишь для пакетного менеджера

    вот именно ГО это мракобесие старого маразматика, ересь не нужна
    когда есть православный Си нуи питон и ява

     
     
  • 2.51, Аноним (-), 11:57, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да, Ява - это и не православно, и не феншуйно, и противоречит гиковскому духу.
     
  • 2.54, Crazy Alex (ok), 22:59, 09/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вот как раз питон на го заменить - самое оно. Порог вхождения примерно одинаковый, простота писанины - тоже. На выходе - хороший контроль типов, лучшее быстродействие и управление зависимостями - хоть своё, а не системное, но из коробки и без чудес.
     

  • 1.55, Вареник (?), 05:42, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Больше несовместимых форматов, хороших и разных!
     
  • 1.60, Аноним (-), 16:07, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Когда-то я задался вопросом, как отлаживать Bash скрипты так, чтобы можно было п... большой текст свёрнут, показать
     
     
  • 2.61, pampa (ok), 16:45, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > <наркомания>
    > Ещё возникает мысль - а не положить ли всю ФС под контроль
    > git и сделать git системным пакетным менеджером тогда уж? (git не
    > принципиален, можно взять другую СКВ).
    > Нужно удалить пакет? - удаляется его коммит, а все, установленные после него,
    > - rebase.
    > </наркомания>

    это было самое первое что я попробовал. Но гит а) плохо работает с бинарниками б) при ребейсе или reset --hard сначала удаляет все дерево, потом линкует его обратно. Соответственно при удалиении всех либ и бинарников система накрывается.

     
     
  • 3.63, Michael Shigorin (ok), 21:50, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > это было самое первое что я попробовал. Но гит а) плохо работает
    > с бинарниками б) при ребейсе или reset --hard сначала удаляет все
    > дерево, потом линкует его обратно. Соответственно при удалиении всех либ и
    > бинарников система накрывается.

    Как днём подумал вслух коллега -- возможно, написать свой git-reset было бы проще.

     
     
  • 4.65, Andrey Mitrofanov (?), 10:46, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> это было самое первое что я попробовал. Но гит а) плохо работает
    >> с бинарниками б) при ребейсе или reset --hard сначала удаляет все
    > Как днём подумал вслух коллега -- возможно, написать свой git-reset было бы
    > проще.

    А для эффективности checkout-ов и коммитов облепить это всё симлик-фармингом, поколениями профилей програм/узеров и системы, гарбидж-коллектором, поставить диск побольше (не сжимать и без git-а)...  Подсказать, |-) где это уже можно посмотреть?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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