Вот не надо про гномосеков и кедарастов! Кс я осилил читать до aptitude install, но он тож неиспользуемые пакеты чистит.... что я делаю не так?

Слава APT! Это лучшее изобретение 21-го века! RPM идет фтопку.

>Вот если его на /usr/bin натравить, тогда -- да, можно чаю заварить и выпить.

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

>Вот чего мне не хватает, так это истории в apt-get, synaptic и Ко. >Было бы удобно. >А то наставил кучу прог (посмотреть, выбрать что лучше,...), а как потом все это удалять?

снапшоты файловой системы, но место на диске потребует тогда побольше

даёшь единый пакетный менеджер!

Re^2: Nix окончательно решит проблему зависимостей

Сусевцы для билдсервиса такую штуку хотят сделать, было недавно обсуждение в рассылке

> > см. /usr/share/doc/apt/examples/configure-index.gz

> Это не мануал. Тебе не трудно процитировать, что именно ты имеешь ввиду, приводя этот файл в пример?


без проблем, расскажу чуть подробнее. тебе и там еще одному анонимусу с аналогичным вопросом.
1. man apt.conf
2. смотрим /usr/share/doc/apt/examples/configure-index.gz на предмет опции AutomaticRemove и кучи других интересных и полезных опций.

теперь понятно?

>Срач как был на винте после установки и удаления так и будет, никто его не решит. deb/apt не решает всех проблем, однако является лучшим на сегодня.

если срать на винты - то никакой менеджер пакетов не спасет

> 3. Да, есть apt-get autoremove. А вы читали как оно работает? apt-get (начиная с некоторой версии) имеет специальный файлик, в который он методично записывает все пакеты, которые установились по зависимости. А при выполнении apt-get autoremove, он ищет среди перечисленных там пакетов те, от которых не зависит пакет, не присутствующий в списке. Всё круто, но. Во-первых, все (!) пакеты, установленные более старой версией apt, есстественно, в этом списке не присутствуют, следовательно в autoremove не участвуют.

Селяви.

> Во-вторых, непонятно как увидеть список пакетов, которые собственно, стоят НЕ как зависимости. Этот список гораздо более важен, т.к. именно он задаёт набор пакетов для автоматической установки.

Можно запросить список таких пакетов через aptitude search. Курить aptitude search patterns.

> И в-третьих, если ошибочно был выполнен apt-get install на пакет, установленный как зависимость, то он из списка стирается, и способов вернуть его назад кроме как отредактировать файл руками (по неведомой причине хранящий больше данных нежели необходимые и достаточные пары название-версия), не наблюдается, что грустно.

Можно, как через CLI так и через GUIок aptitude.

Что? Революция?! А...
Ну, я пойду приму анабиозную ванну, разбудите, когда период полураспада винды закончится.

> Слава APT! Это лучшее изобретение 21-го века!

APT изобрели в 20-м веке.

> RPM идет фтопку.

Сравнение RPM и APT выдает нуба-ниасилятора. RPM надо сравнивать с dpkg, и dpkg по сравнению с RPM - ничего не умеющая поделка.

>Срач как был на винте после установки и удаления так и будет

Почему у меня никакого срача нет и все файлы учтены? Более того, я могу одной командой получить список всех неучтённых файлов. Что я не так делаю? Не тот дистр использую? :)

> Ну и т.п. - дальше уже можно много нафантазировать.

Фантазировать не надо, надо знать, что граф имеет множество представлений в том числе и списковый инциденций, смежности, инверсный и т.д. Кроме того нужно знать, что большие графы не рисуют красиво на экране в виде точечек и рёбрышек, их представляют в виде текстового файла. То есть мы опять пришли к пакетному менеджеру (каждому свой) который по сути и есть обработчик графа.

Далее, для подобных красивостей, чтобы человек мог хотя бы увидеть общие формы отношений объектов представленных графом нужно реализовать алгоритмы размещения, трассировки рёбер. Вы хотя бы на 50 вершин графы видели автоматом размещённые? попробуйте dot - полюбуйтесь. Далее есть жёсткие зависимости а есть мягкие - вес рёбер?...

Короче подвожу вас к мысли что gentoo - то что вам нужно. Ещё бы python выкинули вааще было бы круто.

> Короче подвожу вас к мысли что gentoo - то что вам нужно.

Интересно, здесь хоть кто-нибудь хлодит по ссылкам? :)

<Ъ> I stuck with Gentoo for a lot of years. I still love the sorry little bugger, like I love my senile, toothless, cursing grandpa. But you are out of your fracking mind if you think Portage is the solution to our packaging ills. </Ъ>

> предвидя твои коменты, предлагаю запостить в реквесты на 11.2 кардинальную переработку именно графического пакетного менеджера,

2MadCAD - я пообщался с разработчиками yast2, увы абсолютно невменяемые лица:

новый yast2 не ставиться из-за отсутствия нужной версии zypper - пишу баг, их ответ - еще один пост - удалим усера :)))))))))

> ...такую как использует Debian.

> Только не откладывай, общесснасть ждет. ;)

анонимус, осиль регистрацию!

>Ага, реестр почистить и память соптимизировать... Не надо нам такого, тем более единого.

Об этом речи вообще-то не шло. Да и nix то не под виндовс. Какой уж тут реестр?

>emerge --depclean меня полностью устраивает. Пользователи rpm - ССЗБ. Кликайте по кнопочкам "Ок" в модальных диалогах и дальше...

Так а чем будет плохо если сабж будет уметь не меньше чем портеж? Да и если еще будет уметь больше, и иметь фронт-енд для начинающих? Вы вообще по теме писали, или так, чтоб время убить?

>Это что же, я ставлю-ставлю security update, а эта штуковина продолжает хранить непропатченную версию? И зачем?

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

С чем же тогда APT сравнивать, просвятите?

> С чем же тогда APT сравнивать, просвятите?

С yum или SmartPM. Но есть порт APT для RPM, так что можно и не сравнивать :)

утопия

Localhost administrator reportin` in.
Честно-честно, я не понимаю, какая вам разница, что за пакеты ставятся 
или удаляются apt или rpm. 
Когда я ставлю os с dvd, я всегда отмечаю весь KDE, Gnome, девелоперские группы, etc. 
И это даже с учётом того, что я пользуюсь либо xfce, либо lxde, либо консолью (администратор же :)
И я точно знаю причину, зачем я это делаю: мне нужна os, способная, как
кошерная проститутка, удовлетворить все мои потребности. Хочу играть - пожалуйста, хочу быдлопрограммировать - пожалуйста, хочу красноглазо конпелировать - и этого никто мне не запрети.
Боженька мне в приватной беседе как-то раз сказал, что вместо того, чтобы задумываться о зависимостях и размере свободного места на sda, можно просто купить этот самый sda не на 20 Mb а хотя бы на 80 Gb.
Cheers.

> утопия

Подробнее.

что за нах?. Опять какое то гуано придумали никчемное?

apt и zypper всем устраивают.

>Опять какое то гуано придумали никчемное?

Да. Мама с папой придумали тебя.

>Правильно, не велосипеды делать, а избавится от rpm раз и навсегда.

Не осилил rpm, бедняжка?

>deb/apt не решает всех проблем, однако является лучшим на сегодня

Если бы не лишние телодвижения при сборке пакета из сорцов и проблемы видимости, когда apt не видит вручную установленные через dpkg пакеты (хотя, допустим, брались из репозитория, поддерживаемого этим apt'ом).

> Если бы не лишние телодвижения при сборке пакета из сорцов

а какие там проблемы? мне наоборот всегда казалось что в дебиане опакечивание софта собранного из исходников реализовано самым простым и понятным способом.

>Да. постоянно, устанавливаю прогу, она тянет за собой кучу зависимостей. Удаляю прогу - все накаченные зависимоти не удаляются.

apt-get autoremove

>> Вообще-то есть apt-get purge и apt-get autoremove

>homedir они не трогают. И это правильно.

а также они не трогают конфиги , и это правильно.

>Если бы не лишние телодвижения при сборке пакета из сорцов

dpkg-buildpackage -rfakeroot

это лишние?

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

все он видит, их надо зафиксировать,чтобы они заново не устанавливались.

>>Нет, я лично осилил прочесть рекомендации дебиана про то, что apt-get RIP, и нужно пользоваться aptitude. ;)

>уел, чертяка!
>Ну и сиди теперь с лишними зависимостями.

Вылизать, с анабиоза вам пора.Дебиан головного мозга ?
man aptitude

>а какие там проблемы? мне наоборот всегда казалось что в дебиане >опакечивание софта собранного из исходников реализовано самым >простым >и понятным способом.

DEB уныло, RPM собрать быстрей и проще
1) Есть scr.rpm
2) spec -- очень удобно
3) Не нужен пул
4) Koj -- наше все :)
5) Нет дебильных мягких зависимостей..
6) RPM -- как стрела

DEB -- много минусов
1) Репозиторий УЖАс
2) Нужен пул
3) Архитектурные конфликты i386 vs amd64
4) мягкие зависимости
6) Сложная сборка и средства для этого

> 5) Нет дебильных мягких зависимостей..

Есть.

>Сравнение RPM и APT выдает нуба-ниасилятора. RPM надо сравнивать с dpkg, и dpkg по сравнению с RPM - ничего не умеющая поделка.

похоже на злобное 4.2, что такого умеет RPM, чего не умеет dpkg?

> 5) Нет дебильных мягких зависимостей..
>Есть.

Возможность есть.

Koj читать как Koji

>Если бы не лишние телодвижения при сборке пакета из сорцов и проблемы видимости, когда apt не видит вручную установленные через dpkg пакеты (хотя, допустим, брались из репозитория, поддерживаемого этим apt'ом).

Эээ? С этого момента поподробней, пожалуйста.

1) Есть scr.rpm
Есть deb-src.

2) spec -- очень удобно
debian/ - очень удобно

3) Не нужен пул
тебе какая разница? для сборка пакета пул не нужен

5) Нет дебильных мягких зависимостей..
Ха-ха.

6) RPM -- как стрела
Мда.

DEB -- много минусов
1) Репозиторий УЖАс
?

2) Нужен пул
?

3) Архитектурные конфликты i386 vs amd64
???

4) мягкие зависимости
Это +.

6) Сложная сборка и средства для этого
Дааа... debuild вызвать не каждый джедай может.

>> Сравнение RPM и APT выдает нуба-ниасилятора. RPM надо сравнивать с dpkg, и dpkg по сравнению с RPM - ничего не умеющая поделка.

> похоже на злобное 4.2

Может быть, я новичок в Debian

> что такого умеет RPM, чего не умеет dpkg?

Цифровые подписи, проверку зависимостей при инсталляции, транзакции. В SRPM он умеет несколько патчей, а не один мегапатч, как в deb.

З.Ы. Не судите сборку deb'ов по тому уродству, которое есть в OpenSUSE build service.

>> Суть в том, что нужно сделать модуль к какой-нибудь программе управления пакетами, который будет отображать установленные/доступные пакеты в виде направленного графа, отображающего зависимости между ними (пакет - вершина, зависимость - ребро).

> Я джва года хочу такой менеджер пакетов.

В Suse yast так умеет.

>Цифровые подписи

Это задача APT'a.

>проверку зависимостей при инсталляции

Удивил :/ dpkg умеет это, конечно же.

>транзакции

тут под вопросом, можно ссылку на описание?

>В SRPM он умеет несколько патчей, а не один мегапатч, как в deb.

Подскажу: в этот "патч" можно положить директорию debian/patches/, в которую и кладутся нужные патчи.

>>Цифровые подписи

>Это задача APT'a.

То есть dpkg этого не умеет. О чем и речь.

>>проверку зависимостей при инсталляции

>Удивил :/ dpkg умеет это, конечно же.

Что-то я этого не заметил - dpkg ставит пакет, потом не может его сконфигурировать из-за отсуствующих зависимостей.

Из мана: "Warning: At present dpkg does not do any dependency checking on downgrades and therefore will not warn you if the downgrade breaks the dependency of some other package."

>>транзакции

> тут под вопросом, можно ссылку на описание?

Нет. У меня уже Дебиан %)

>>В SRPM он умеет несколько патчей, а не один мегапатч, как в deb.

>Подскажу: в этот "патч" можно положить директорию debian/patches/, в которую и кладутся нужные патчи.

Может, подскажешь и пакет, в котором так сделано?

>>Цифровые подписи, проверку зависимостей при инсталляции, транзакции. В SRPM он умеет несколько патчей, а не один мегапатч, как в deb.

не надо это ему всё. Это низкоуровневая утилита для работы с пакетами, а не менеджер.

Подписи умеет apt.
Зависимости умеет apt.
Мегапатч - это дибианизирущий патч, в которой могут входить debian/patches/, как уже сказали. Эти патчи накладываются либо подряд, либо в указанной тобой последовательности.

>Есть deb-src.
Где ?
>Архитектурные конфликты i386 vs amd64
Установите пакет i386 на Debian amd64
>4) мягкие зависимости
>Это +.
Ну, и в чем полюс?
>Дааа... debuild вызвать не каждый джедай может.
Сборка пакетов это не только debuild :) или rpmbuild
>тебе какая разница? для сборка пакета пул не нужен
Дя? мне вот нужен был.Так как собирал не только под Leny

>>Может, подскажешь и пакет, в котором так сделано?

таких много. mc и alsa например, это из того, что я ковырял последнее время.

>Если подключено 10 сетевых репов, но сеть недоступна, на каждый реп нужно будет нажать кнопочку ОК, согласившись с тем, что реп недоступен, а потом во втором окошечке еще кнопочку "пропустить". Итого 20 нажатий, хотя я всего лишь хотел удалить пакет.

хм... Yast2 (который "Параметры администратора" в меню) - "Репозитарии программного обеспечения" - поснимать галочки с автообновления в каждом из них.

Нужно обновиться - заходишь туда же и клацаешь "Обновить сейчас".

Это конечно не панацея, но как компромисс сойдёт.

А вообще-то yast --install (ты прав) - тупое тормозящее говно. После Дебиана особенно.

glibc

> новый yast2 не ставиться из-за отсутствия нужной версии zypper - пишу баг, их ответ - еще один пост - удалим усера

Похоже на ложь. Сейчас по описанию непонятно в каком пакете у тебя "неверная" зависимость. Часть модулей yast зависят от libzypp (что вообще-то вполне нормально), но вот от zypper они не зависят.

Функциональность пакетного менеджера тут вынесена в библиотеку. Соответствующий модуль yast и zypper - пользовательские интерфейсы к этой библиотеке. В чем баг?

Скорее всего ты стал пороть чушь, бразгая на всех слюнями - вот и пригрозили удалить пользователя. Если же не так - ссылку дай на соответствующую страницу bugzilla.

>>Цифровые подписи, проверку зависимостей при инсталляции, транзакции. В SRPM он умеет несколько патчей, а не один мегапатч, как в deb.

> не надо это ему всё. Это низкоуровневая утилита для работы с пакетами, а не менеджер.

Точно так можно сказать, что RPM не нужно управление зависимостями и репозиториями, потому что это менеджер пакетов, а для зависимостей и репозиториев есть Yum или тот же APT.

> Мегапатч - это дибианизирущий патч, в которой могут входить debian/patches/, как уже сказали. Эти патчи накладываются либо подряд, либо в указанной тобой последовательности.

В RPM эти патчи всегда сохраняются в src.rpm по отдельности. В deb, похоже, они всегда объединяются (буду рад ошибиться).

Да я штуки четыре улучшения в Yast пропихивал через багзиллу - всё было нормально.

> Поставил на ночь обновление, с RC до релиза, яст пообещал слить 2 с лихом гига. Утром открываю, вижу сообщение: "Timeout exceeded". И одна кнопочка - Ок.

Естественно. Пользователь должен быть извещен об ошибке.

--skip-interactive Можно и так.

А еще лучше прописать немецкие зеркала (Timeout exceeded - признак yandex зеркала). А при быстром канале пользоваться metalink.