>Из мана: "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."

Ключевая фраза - 'on downgrades'. Debian даунгрейды не поддерживает официально.

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

Подавляющее большинство пакетов с патчами на сейчас. Если хочешь пример, возьми хотя бы html2text тот же.

>>Есть deb-src.
>Где ?
Как это где? Документацию читай. Да хотя бы /usr/share/doc/apt/examples/sources.list

>Установите пакет i386 на Debian amd64
Очень надо? Без подходящих либ? Ну вручаю тебе '--force-architecture'.

>Ну, и в чем полюс?
Более гибкая система зависимостей.

>Сборка пакетов это не только debuild :) или rpmbuild
А, так тебе процесс важен? Ну тогда развивай тему, послушаю.

>Дя? мне вот нужен был.Так как собирал не только под Leny
Если ты репозиторий делал, да, пул нужен. Только он, опять же, автоматически создаётся соответствующими утилитами построения репозитория, без ручного вмешательства.

>В deb, похоже, они всегда объединяются (буду рад ошибиться).
Угу, ошибаешься. Вполне себе хранятся в первозданном виде.

>> Из мана: "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."

> Ключевая фраза - 'on downgrades'

Неа, ключевая фраза - "не сконфигурировался из-за отсуствия зависимостей". Отсуствие проверки на даунгрейде меня пока не волновало.

> Debian даунгрейды не поддерживает официально.

Бгг. Такой вот гибкий Дебиан %)

Буууа ))
Раздули DEB vs RPM
Оба они хороши, так как создаются людьми для людей !
Если кому то что-то не нравится. Берем компилятор в зубы, любим текстовой редактор в руки, git вам в помощь и начинаем !! :)
nix -- не плохая идея..

>Как это где? Документацию читай. Да хотя бы /usr/share/doc/apt/examples/sources.list
Хоцу посмотреть репозитроий.. скачать файл:) ссылку дайте. Я в MAC OS сейчас.
>Очень надо? Без подходящих либ? Ну вручаю тебе '--force-architecture'.
Очень... и вот именно либы и чтобы все работала без костылей.
>А, так тебе процесс важен? Ну тогда развивай тему, послушаю.
1) rpmbuild может собирает под архитектуры i386 и amd64
2) Koji и mock позваляет просто и не принуждено собирать под разные RPM дистрибутивы.
> Более гибкая система зависимостей.
Спорный момент

>ссылку дайте. http://ftp.de.debian.org/debian/pool/main/h/html2text/html2text_1.3.2a-5.diff.gz

>чтобы все работала без костылей. ты уже изначально запросил костыль, костыль и получил

>rpmbuild может собирает под архитектуры i386 и amd64 а dpkg-buildpackage - под дюжину архитектур, и что?

>Koji и mock позваляет просто и не принуждено собирать под разные RPM дистрибутивы. Что, без проверки на каждом из этих дистрибов? В таком случае это "для галочки".

Блин, таки забыл user-line breaks поставить. Надеюсь, и так понятно.

>начинающий пользователь мог через фронтенд в три клика мышью установить, обновить или удалить приложение, и чтобы красноглазик смог собрать любимую прогу В Arch линуксе такое уже есть.

профиль же

>> Koji и mock позваляет просто и не принуждено собирать под разные RPM дистрибутивы.

> Что, без проверки на каждом из этих дистрибов? В таком случае это "для галочки".

Почему? Собранные пакеты направляются на проверку, и, возможно, пройдут ее :)

>профиль же

Спасибо :) Чего только не узнаешь в треде про пакетные менеджеры :)

>чтобы все работала без костылей. ты уже изначально запросил костыль, костыль и получил

Это у Вас Дебиан головного мозга.В rpm-баседах я могу свободно работать с i386

>rpmbuild может собирает под архитектуры i386 и amd64 а
dpkg-buildpackage - под дюжину архитектур, и что?

На одной станции ?

>Koji и mock позваляет просто и не принуждено собирать под разные RPM дистрибутивы. Что, без проверки на каждом из этих дистрибов? В таком случае это "для галочки".

Представьте, там все работает без проблем.Для этого и создавались

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

Я не думаю, что разработчики твоей бубунты настолько тупые, чтобы не реализовать какой-нибудь depclean

>ссылку дайте. http://ftp.de.debian.org/debian/pool/main/h/html2text/html2text_1.3.2a-5.diff.gz

что вы мне дали ? мне нужен например mc src deb :)

>Это у Вас Дебиан головного мозга.В rpm-баседах я могу свободно работать с i386

Угу, то-то у меня коллеги плевались... Библиотеки основные у вас в 2-х экземплярах установлены - под 64 и 32 бита, так?

У Debian есть замечательная штука - debootstrap. В чрут и собирать под 32 бита хоть до посинения. И потестировать можно. А если в официальный репозиторий собираешь, дак там всё за тебя соберут.

>Представьте, там все работает без проблем.Для этого и создавались
Как интересно... и что, ситуация, когда в одном дистрибутиве один SONAME у зависимой библиотеки, в другом - другой, тоже автоматически обрабатывается? А если версии у build-depends разные? А кто будет тестировать с разными версиями зависимостей программу?

http://packages.debian.org/source/sid/mc

>apt удаляет пакет так же,как способна удалить его сейчас,но с определённым ключем удаляла бы всё и вся,включая мусор в ~

А список пользователей (помним, что линукс система изначально многопользовательская) берёт из LDAP. Красота. Главное, не сложно это.

Чёрт, как так? На машине юзера Васи эта программа стоит и всё ещё нужна, а настройки уже удалились.

Не должны пакетные менеджеры трогать /home, ни в каком виде.

>Библиотеки основные у вас в 2-х экземплярах установлены - под 64 и 32 бита, так?
Если есть для этого необходимость
>debootstrap
Видели мы это.. еще то чудо.
>Как интересно... и что, ситуация, когда в одном дистрибутиве один SONAME у зависимой библиотеки
Повторюсь для этого есть mock и koji

>http://packages.debian.org/source/sid/mc
У Вас, что с головой, точно деб головного мозга?
я просил mc src.deb :) где он ?
вот вам http://mirror.yandex.ru/fedora/linux/releases/10/Everything/source/SRPMS/mc-4...

где mc-4.6.2-7.pre1.src.deb ? ))

>Не должны пакетные менеджеры трогать /home, ни в каком виде.

Не слушай их, они, видимо, обкурились. Не трогает никто /home, ни под каким видом.

Три ссылки внизу страницы осилил увидеть? Вот это и есть deb-src.

Народ, подскажите, пожалуйста, как мне удалить Transmission?

Вот тут проблема видна: http://verger1.narod.ru/transmission-gnome.ogv

>Три ссылки внизу страницы осилил увидеть? Вот это и есть deb-src.

Где файл?не файлы а файл;) все ясно с вами, у Вас "деб" головного мозга.
и вы мне не тыкаете пожалуйста..

>Сделали бы допустим так: apt удаляет пакет так же,как способна удалить его сейчас,но с определённым ключем удаляла бы всё и вся,включая мусор в ~

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

>Где файл?не файлы а файл;) все ясно с вами, у Вас "деб" головного мозга.
deb != rpm => deb-src != src.rpm. deb-src - это именно три файла. Get it.

>и вы мне не тыкаете пожалуйста..
замётано

led, перелогинься, дебил

>>где mc-4.6.2-7.pre1.src.deb ? ))

по мойму у тебя rpm головного мозга, ты не замечаешь?

>Так сложно почистить вручную? Это даже при сильно засранном /home пятиминутное дело.

rm -rf =)

Sun-ch переориентировался. Это конец, Света.

Проблем у них нету! А поставить OO-2.4 и OO-3.0 одновременно? А чтобы ещё у двух пользователей разные версии по-умолчанию? А ещё gcc-3.4 gcc-4.3, разные для разных пользователей - это как в прекрасном дебиане сделать? Не говоря уже даунгрейде, вечно протухших пакетах и произволе майнтейнеров. Конечно, кто не работает - у тех проблем нет.

>Да. Мама с папой придумали тебя. anonymous (*) (24.12.2008 13:46:28)

Я твой рот ебал, черт ебаный. Очередная малолетка, которая ощущает себя ахуевшим перцем под аноним.

>deb != rpm => deb-src != src.rpm. deb-src - это именно три файла. Get it

О вы это знаете !!! так что вы мне говорили? что есть такое-же в дебе как src.rpm ? нету...
нету, да?... ;)

>по мойму у тебя rpm головного мозга, ты не замечаешь?

Почему, я не плохо разбираюсь и в DEB :) я не говорил что есть mc-4.6.2-7.pre1.src.deb ...
Это вы зря.

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

Ну если настолько все запущено, что каждому юзеру свой зоопарк софта нужен... ну в разный chroot их посади что ли...

>что есть такое-же в дебе как src.rpm ? нету...
нету, да?... ;)

Троллите, похоже. src.rpm - то, из чего собирается rpm. deb-src - то, из чего собирается deb. Что-то не нравится?

>Кстати, а почему не видно в комментариях Slackwar'щиков с утверждениями про сидящий за компьютером главный пакетный менеджер и божестевенность Патрика? Зимняя спячка началась?

Выступлю за Slackware'щиков:

"Окончательное решение проблемы зависимостей - это уничтожение всех зависимостей!" Ж;-)

>Ну если настолько все запущено, что каждому юзеру свой зоопарк софта нужен... ну в разный chroot их посади что ли...

не нужен chroot. Данные у них общие, системный софт общий. Просто у каждого свои предпочтения. Один файрфокс 2.x86-64 иользует. а другой - 3.i386. Но в случае необходимости каждый может запустить любую сборку программы. Накатить новую версию, не удаляя старую и потом вернуться обратно.

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

>Троллите, похоже. src.rpm - то, из чего собирается rpm. deb-src - то, из чего собирается deb. Что-то не нравится?

Просто нельзя сравнивать один файл(src.rpm) с кучей(deb-src).
Конечно я не много извиняюсь за вопросы, на которые знал ответы.

>Что, без проверки на каждом из этих дистрибов? В таком случае это "для галочки".

это build-farm. Для сборки пакета создает чистую песочницу и собирает в ней.

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

_Полное_ дерево зависимостей вплоть до xorg и libc... Месье знает толк в извращениях!

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

Где??? У меня куча мусорных зависимостей осталось. Скакой стороны начать разгребать ее даже не представляю. Можно ссылочку?

>Я твой рот ебал, черт ебаный. Очередная малолетка, которая ощущает себя ахуевшим перцем под аноним.

Охуевший перец здесь ты. Действительно, мама с папой зря тебя придумали.

Ура! Cвершилось.

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

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

Подвожу вас к google и мысли про portage 2.2, Paludis, pkgcore. Как говориться? лучше новый велосипед нежели старый фенить?

любопытный сабж. Язык рецептов напоминает хаскелль.
Кастую в топик сравнение пакетных менеджеров: portage,paludis, pkgcore, nix.
Интересно, а default.nix можно автоматически из готовых ебилдов строить?
И да, непонятно что там с бинарными пакетами. В смысле, если они есть, они должны скачаться Nix'ом. Но если их нет, и что-то собирается в первый раз, кто будет заливать бинарник, считать sha-сигнатуру, и т.п.? Вот например, если строим ебилдами пакет с одним набором USE-флагов, потом пересобираем с другим набором. Portage тупо пересоберет заново, возможно вывалится на этапе компиляции если зависимости не удовлетворены (с новым набором USE-флагов, хотя со старым удовлетворялись). А что будет в Nix? Будет два отдельных бинарника с двумя наборами USE-флагов, и они после сборки автоматически закачаются в репозиторий?
Итого, другая структура "профиля" (категории, названия пакетов, соглашения по именованию). Другая система контроля зависимостей (всё по умолчанию ставится "в слоты", как в DVCS любой бранч -- это новый репозиторий). Другой формат "ебилдов". Бинарники собранные должны сразу скачиваться. А чего нового появилось в Nix, чем он лучше paludis, pkgcore или того нового менеджера в дистре Exerbro ( или как-то так, который "на основе Генту")?

s/соглашения по именованию/соглашения по именованию версий пакетов/

ещё непонятно, почему в сабже https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/ используется SVN. Почему не git, с обновлениями rsync'ом нахаляву (они к тому же похожи: что в git, что в nix предлагают периодически запускать fsck/"сборщик мусора" nix-collect-garbage). И кто там боялся, что "ментейнеров надо будет опрашивать на предмет USE-флагов" -- просто положите их в git и реплицируйте на здоровье. "Лежит в репозитории пакет и 'make.conf' с конкретным набором USE-флагов " === "пакет гарантированно собирается с указанным набором флагов"

> 1. Задача несколько одновременно стоящих версий одного пакета изящно решена в emerge с помощью понятия SLOT.

не так уж "изящно". Если ебилд не слотовый, надо будет переделать его и все его зависимости, чтобы они узнали о новом слоте. (Например, что там вылезло при недавнем обновлении KDE-3 на KDE-4 -- ненужная пересборка пакетов, потому что ебилды изменились. А что-то наверно до сих пор не вылезло, сидит какой-то старый ебилд с qt вместо qt-3 и его придётся переделывать).
А в 0install, или тут, или в git он автоматически пойдёт в "новый бранч".

>>8. > and allows a choice of SQL back ends on installation.

>Это прикол что ли, они конфиги в sql-базе хранят?

не, это вроде хранения базы пакетов из портежа в mysql (FEATURES="metadata-transfer", например, чтобы rdep.py работал моментально)