[Debian][вопрос-ответ] Debian-way

Почему dpkg 2.0 "не взлетел" и планируется ли существенные модернизации системы управления пакетами??

Каково будущее apt-get и уеби^Wотврати^W aptitude?

>Почему dpkg 2.0 "не взлетел"

А должен был? На данный момент мне не известно ни одной фундаментальной проблемы dpkg и плана, по которому что-то должно резко меняться и выпускаться вторая версия. Некритичные ошибки, конечно, есть, и они потихоньку исправляются.

>Каково будущее apt-get и уеби^Wотврати^W aptitude?

Хороший вопрос :) В целом, утилиты свои задачи выполняют, и большинство пользователей удовлетворяют, хотя проблем тоже хватает. Разработка apt-get (libapt, в общем-то) ведётся крайне медленно, не хватает заинтересованных людей. Daniel Burrows, разработчик aptitude, работает традиционно активно, и aptitude планомерно пилится.
Также в январе стартовал проект альтернативного фронт-энда для dpkg, называемый 'Cupt', основная цель которого - написание более чистой и расширяемой кодовой базы пакетного менеджера, чем libapt. Кто желает, текущую версию можно пробовать из Debian unstable (пакет 'cupt').

А чем aptitude не угодил? Не, честно, только без слюней, только факты... =)

>> Почему dpkg 2.0 "не взлетел"

> А должен был?

Ну мне лично - нет, но dpkg как диалоговый инструмент уеби^W с RPM просто не сравнить. Такое впечатление, что в нем куча рудиментов со времен до apt (то, что dpkg-query -W выдает названия даже удаленных пакетов - хорошее тому свидетельство; для получения списка установленных пакетов приходится писать однострочник на шелле). И цели у dpkg 2.0 были здравые - библиотечный интерфейс, работа только со списком установленных пакетов... В общем, нормальная такая версия 2.0.

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

Я периодически читаю, что apt-get вроде как deprecated, это так?

> в январе стартовал проект альтернативного фронт-энда для dpkg, называемый 'Cupt'

Да, это Debian-way - под лозунгом "Работает - не трогай" городить стройные ряды костылей :/ Это уже 3-я надстройка над dpkg или 4-я (считая tasksel)?

> только без слюней, только факты... =)

Давай будем считать, что я ответил тебе хамством, каким именно - можешь придумать сам.

>для получения списка установленных пакетов приходится писать однострочник на шелле

dpkg --get-selections не оно?

>И цели у dpkg 2.0 были здравые - библиотечный интерфейс

Это разработчики обещают сделать. Хотя временных рамок нет.

>Такое впечатление, что в нем куча рудиментов со времен до apt (то, что dpkg-query -W выдает названия даже удаленных пакетов - хорошее тому свидетельство; для получения списка установленных пакетов приходится писать однострочник на шелле).

Частично согласен, хотя особо не напрягает. Напиши wishlist bug на dpkg.

>Да, это Debian-way - под лозунгом "Работает - не трогай" городить стройные ряды костылей :/

Проект нацелен на решение конкретных проблем, про костыли не понял. Вот есть проект (parted). К нему есть два известных фронт-энда - gparted и qtparted. Так что ж, один из них - костыль? Есть конкуренция, есть выбор для администратора. Для решения одной и то же задачи может быть несколько инструментов, и это нормально (з.ы. а ещё есть малоизвестные dselect и wajig).

>> для получения списка установленных пакетов приходится писать однострочник на шелле

> dpkg --get-selections не оно?

Нет, оно тоже подмешивает в список удаленные пакеты (хотя и честно помечает их). То есть это лучше, чем dpkg-query -W, но какого рожна dpkg вообще сообщает о не-инсталлированных пакетах? Это задача apt или подобного инструмента.

ну, dpkg -l дает список
хотя и его надо и очищать :))

>но какого рожна dpkg вообще сообщает о не-инсталлированных пакетах?

В некоторых случаях это правильно, так как в Debian состояние пакета не ограничивается двумя installed/not installed. Помимо промежуточных при операциях, есть ещё 'config-files'. Это означает, что, хотя сам пакет был удалён, конфигурационные файлы (обычно это /etc/*) для него удалены не были. По-умолчанию (действие 'remove') они не удаляются, для удаления нужно сделать 'purge' пакету.

> Вот есть проект (parted). К нему есть два известных фронт-энда - gparted и qtparted. Так что ж, один из них - костыль? Есть конкуренция, есть выбор для администратора

Да как сказать... в случае apt/aptitude я вижу только распыление сил. Ну зачем в aptitude нужен был ncurses-интерфейс (угребищный до невозможности, ИМХО)? И, если aptitude и apt оба сделаны поверх libapt, почему было просто не добавить smarter dependecu resolution и mutt-like queries к apt? Free software такое free :/

Насчет того, что apt-get - deprecated, это так?

> В некоторых случаях это правильно, так как в Debian состояние пакета не ограничивается двумя installed/not installed.

Но оно же показывает и removed, и вроде даже purged.

>Да как сказать... в случае apt/aptitude я вижу только распыление сил.

Собственно, у aptitude своего только интерфейс, решатель зависимостей и несколько полезных фич типа продвинутого поиска. Остальное всё также идёт через libapt.

>Ну зачем в aptitude нужен был ncurses-интерфейс (угребищный до невозможности, ИМХО)?

Я лично его тоже не люблю, но кому-то же нравится :). И интерфейс командной строки у него очень неплох.

> Насчет того, что apt-get - deprecated, это так?

Формально говоря, нет. На сейчас (lenny) более рекомендуемым для юзеров официально является aptitude. Однако, немалая часть инфраструктуры Debian использует apt-get, и среди разработчиков достаточно тех, кому apt-get нравится больше, чем aptitude.

> почему было просто не добавить smarter dependecu resolution и mutt-like queries к apt? Free software такое free :/

Я ж говорю, людей не хватает.

> Насчет того, что apt-get - deprecated, это так?

А это настойчивый и навязчивый бред попов от Debian с ака linuxforum.:)
1: Простое не умирает , и мода тут не при чем
2: Что проще - то ,менее "ломается" и подводит.
3: В встроенных системах apt-get & dpkg c головой хватает.

>> В некоторых случаях это правильно, так как в Debian состояние пакета не ограничивается двумя installed/not installed.

>Но оно же показывает и removed, и вроде даже purged.

Ключевая фраза - "в некоторых" :). А что, кому-то полезно видеть, какие пакеты были установлены когда-то. А кому нет, то grep "^ii" сделать легко. Собственно, если это самая сложная задача, которая встаёт перед админом, то этому админу можно позавидовать :)

> Я периодически читаю, что apt-get вроде как deprecated, это так?

Меня этот вопрос тоже интересует. Мне кажется, это наглые провокационные слухи, но вижу я их очень часто :-(

> А что, кому-то полезно видеть, какие пакеты были установлены когда-то.

Сейчас попробовал dpkg-query -l \* - он выдал чертову уйму пакетов, которые у меня на машине никогда и не стояли %) Прикольно, к чему могут привыкнуть люди...

> Да как сказать... в случае apt/aptitude я вижу только распыление сил. Ну зачем в aptitude нужен был ncurses-интерфейс (угребищный до невозможности, ИМХО)? И, если aptitude и apt оба сделаны поверх libapt, почему было просто не добавить smarter dependecu resolution и mutt-like queries к apt?

Во, первых, +1, а во-вторых, кинь плиз ссылку, где прочесть про аптитудовские smarter dependecu resolution и mutt-like queries. (всегда обходился без этого, но интересно стало)

Ответ - http://www.linux.org.ru/jump-message.jsp?msgid=3774713&cid=3774927

я использую для вывода чистого списка пакетов:
$ dpkg -l | grep ii | awk '{print $2}'

> Сейчас попробовал dpkg-query -l \* - он выдал чертову уйму пакетов, которые у меня на машине никогда и не стояли

У меня (хлипкая) гипотеза -- может там рекомендуемые пакеты?

> Прикольно, к чему могут привыкнуть люди...

Да, я привык к | grep ^ii

> dpkg --get-selections не оно?

У меня оно выдает несколько строчек вида

squid deinstall

(хотя да, там конфиги остались).

>Нет, оно тоже подмешивает в список удаленные пакеты (хотя и честно помечает их).

Может вы просто не делаете purge?

> Ответ - http://www.linux.org.ru/jump-message.jsp?msgid=3774713&cid=3774927

Лично мне идея объявить apt deprecated очень не нравится. По крайней мере для меня оно работоспособно.

можно еще проще:
#wajig list-installed

>Но оно же показывает и removed, и вроде даже purged.

Полно purge'd пакетов было. Не показывает.

>Лично мне идея объявить apt deprecated очень не нравится. По крайней мере для меня оно работоспособно.

Ещё бы. Поэтому никто и не объявляет.

> У меня (хлипкая) гипотеза -- может там рекомендуемые пакеты?

Как я щас выяснил, в список dpkg -l \* и dpkg-query -l \* попадает даже 1 пакет, который никогда не стоял, нигде не рекомендуется, а конфликтует с установленным.

Почему dpkg зависит от coreutils? (причем начиная с ленни!) Это как-то не очень модульно вроде.

http://packages.debian.org/lenny/dpkg

>Почему dpkg зависит от coreutils? (причем начиная с ленни!) Это как-то не очень модульно вроде.

Там не простая зависимость, а усиленная (Pre-Depends), что значит, что coreutils не ниже указанной версии нужна на раннем этапе установки пакета dpkg (до распаковки), вероятно, для манипуляций с файловой системой в предустановочных скриптах.

Хотя претензию не понял. Не думал, что кого-то смутит зависимость от coreutils, обязательного (essential) пакета :)

> Хотя претензию не понял. Не думал, что кого-то смутит зависимость от coreutils, обязательного (essential) пакета :)

Допустим, не хочу я coreutils, а хочу busybox и dpkg.

Покажи что тебе не нравится в выводе dpkg-query.

Кстати, еще один вопрос: для сборки RPM-пакетов есть "Maximum RPM" (всё, что надо знать о сборке пакетов с RPM v3, и много больше). Есть ли аналог для dpkg?

>я использую для вывода чистого списка пакетов:

> $ dpkg -l | grep ii | awk '{print $2}'

Я бы написал grep ^ii, но пойнт в другом - так можно докатиться и до прямого разбора /var/lib/dpkg/status.

Я бы написал

$ dpkg -l | awk '/^ii/ {print $2}' 

> Я бы написал

> $ dpkg -l | awk '/^ii/ {print $2}'

Так даже лучше, но хочется примерно так: rpm -qa

> Так даже лучше, но хочется примерно так: rpm -qa

Ставь Федору, не мучайся =)

Тогда уж

> Ставь CentOS, не мучайся =)

fixed =)

>> Так даже лучше, но хочется примерно так: rpm -qa

>Ставь Федору,

Вот когда в ней появятся ARM и MIPS, а базовая система раза в 2 меньше, - я вернусь... может быть :) Да и по слухам, поддержка PowerPC в Debian получше будет.

> не мучайся =)

Я всё еще надеюсь привыкнуть :)

А тебе столько платформ для чего-то нужны?

Торвальдс на Fedora/PPC сидит :)

Почему у xorg в жестких зависимостях стоит hal?

> А тебе столько платформ для чего-то нужны?

Могут понадобиться (особенно ARM), да и запас карман не тянет.

> Торвальдс на Fedora/PPC сидит :)

Торвальдс - это та инопланетная тварь, которая зохавала моск Линуса, и заставила его написать Git и купить Mac? No wai.

А какая инопланетная тварь заставляет собирать пайп с awk или grep? :)

>для сборки RPM-пакетов есть "Maximum RPM"

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

Гы-гы, tailgunner - чайник =)

http://www.debian.org/doc/maint-guide/ для затравки, затем http://www.debian.org/doc/developers-reference/ и http://www.debian.org/doc/debian-policy/.

>Почему у xorg в жестких зависимостях стоит hal?

Решение сопровождающих xorg в Debian, что овчинка выделки не стоит. Согласны не все, понятное дело :)

> У дебиана есть отличный мануал на эту тему, с подробными инструкциями. А когда чайники бросаются собирать пакеты - выходит редкостное гуано.

Я читал эти мануалы. Как руководство по сборке, им до Maximum RPM как... ну, в общем, далеко. Собственно, поэтому я и спрашивал про книгу - всякие HOWTO по сборке RPM тоже глубиной не отличаются.

а попробуй:
http://www.togaware.com/linux/survivor/Wajig_Overview.html
удобно и меньше забывать надо

> Так даже лучше, но хочется примерно так: rpm -qa

aptitude search ~i