Пакетные дистрибутивы - тупиковая ветвь? (SRC и RPM/DEB)

[xorader]

Как пакетные , так и source-base , так и другие какие будут потом (может по типу
install в windows  ) - все они имеют права на существование ,кааждому пользователю как говориться свой дистр 
А то что пакетный тупиковый я не согласен , посмотрите -Suse ,Red Hat итд
неплохие растущие прибыли за счёт продажи своих дистров на основе пакетов .

Далее я согласен с Александро , попробуй выполнить задачу и установить с полной
настройкой на  4-6 машин например Gentoo (скажем так это твоя зарплата ?) в 1 день

↑

Всё в точности до наоборот! Если есть сеть, то рабочего времени займёт на всё меньше чем с пакетниками в разы ! Это не голословное утверждение, а опыт!
Буквально вчера с человеком общался по этому поводу - повторюсь.

Разговор про gentoo:

Код: Выделить всё

[2004-07-04 16:17:58]<xor> поконфигурябельней она и проще в обслуживании (когда разберёшься)
[2004-07-04 16:17:59]<random_code> ну это понятно. мне просто интересно стало, кто быстрее :)
[2004-07-04 16:19:04]<xor> а на скорость мне положить... я на gentoo не из-за скорости... мне плевать на 5% или даже меньше
[2004-07-04 16:19:29]<random_code> и из-за чего же на gentoo сидеть?
[2004-07-04 16:19:49]<random_code> из-за портежей?
[2004-07-04 16:20:12]<xor> мда... приехали... из-за простоты обслуживания...  я такого удобства и продуманости в /etc + безопасности ни в одном linux'е не видел
[2004-07-04 16:20:20]<xor> да.. из-за портов
[2004-07-04 16:20:35]<xor> etc-update чего стоит и прочие вкусности
[2004-07-04 16:21:10]<xor> потом единственный linux который боле менее справляется с зависимостями... другие рядом не стояли
[2004-07-04 16:21:23]<random_code> да, согласен.
[2004-07-04 16:22:24]<xor> а то что народ его позиционирует и считает главным достоинством - скорость.... так это просто смешно! обидно что главные прелести не упоминают а на скорость давят... [skiped] :)
[2004-07-04 16:23:01]<xor> http://www.gentoo.org/main/en/philosophy.xml
не одного упоминания о скорости :)
[2004-07-04 16:23:32]<xor> не ну намёки есть конечно, но... ты меня понял :)
[2004-07-04 16:24:19]<random_code> просто надоело - тачку апгрейдишь, а тольку чуть
[2004-07-04 16:24:24]<xor> red-hat red-hat..... там такие проблемы начинаються после полгода активного юзанья и установки-удаления-обновления софта... нафик нафик
[2004-07-04 16:24:49]<xor> а потом переустанавливать каждый год на новую версию.. в гробу я это видел когда серваков дое[<censored>]&^@
[2004-07-04 16:25:04]<random_code> да, ффтопку. МДК, АСП, Альт - ффтопку три раза :)
[2004-07-04 16:25:10]*xor nods

Добавлю ещё:
- именно с gentoo приходит понимание, что происходит с машинками при обновлениях, а на серверах это очень важно, где крутятся большие деньги!!! Мне лично это особенно актуально, так как я стараюсь вникать полностью в софтинку (даже порой сырки просматриваю) перед её использованием (отсюда обычно рождаються мои feedback'и).
- при грамотном подходе (а именно, distfiles через nfs + локальный rsync server для portage + общая папка packages у похожих серверов) обновление серверов кушает минимум трафика и времени админа! [спорить не буду, что это на любом пакетном дистре делается, но чего то не хватает... некоторых вкусностей - изюминки]
- устранение критичных дыр максимум в течении 24 часов, а на bugs.gentoo.org всё это можно нарыть в разы быстрее + развивающийся проект glsa в gentoo
- повторяюсь: на сервере нет лишнего и все файлы на месте и понятно что для чего... это особенно замечаеться после года активного использования/обновлений софта
- и вообще, вы представляете весь ГЕМОРОЙ при переходе от одной версии того же RedHat к примеру на другую (бакап, снос партишенов, восстановление всех сервисов, конфигурация заново, и при этом нужно ещё поднимать резервный сервер для критических сервисов так как вас никто ждать не будет, как в домашней песочнице локальной сети !!!!) и в сравнении с этим сказочную лёгкость emerge sync && emerge -vuD world !!!!

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

[Warderer]

- и вообще, вы представляете весь ГЕМОРОЙ при переходе от одной версии того же RedHat к примеру на другую (бакап, снос партишенов, восстановление всех сервисов, конфигурация заново, и при этом нужно ещё поднимать резервный сервер для критических сервисов так как вас никто ждать не будет, как в домашней песочнице локальной сети !!!!) и в сравнении с этим сказочную лёгкость emerge sync && emerge -vuD world !!!!

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

↑

Согласен. Не в меньшей мере из-за ухода от версионности перешел на Debian. После того как для апдейта SuSE 8.2, занимающий на винте 1.2 ГБ попросил выкачать 2.7 гига я послал его нафиг...
emerge sync && emerge -vuD world практически равнозначен с apt-get update && apt-get dist-upgrade

[Shurik]

Ребят, у меня складывается такое впечатление, что никто не слышал об yum. Равно как и apt-get под ту-же Федору. И в первой и во второй программе имеется такая опция, которая обзывается UPGRADE, т.е. банальное ОБНОВЛЕНИЕ пакетов, которые установлены. Абсолютно никто не заставляет запускать тот-же yum с опцией UPDATE, когда обновляются и УСТАНАВЛИВАЮТСЯ ВСЕ новые пакеты, которые есть на репрозитории пакетов, т.е. производится ПОЛНАЯ установка дистрибутива. Обнови существующие и радуйся жизни.

[madskull]

Ребят, у меня складывается такое впечатление, что никто не слышал об yum. Равно как и apt-get под ту-же Федору. И в первой и во второй программе имеется такая опция, которая обзывается UPGRADE, т.е. банальное ОБНОВЛЕНИЕ пакетов, которые установлены. Абсолютно никто не заставляет запускать тот-же yum с опцией UPDATE, когда обновляются и УСТАНАВЛИВАЮТСЯ ВСЕ новые пакеты, которые есть на репрозитории пакетов, т.е. производится ПОЛНАЯ установка дистрибутива. Обнови существующие и радуйся жизни.

↑

Скажи, только честно: ты делал yum update или apt-get upgrade на rpm-based дистрах? Ну и какие результаты?

Я делал:
apt-get в ALM 2.0 -> Сизиф - нарушение зависимостей и иногда падение системы;
yum в ASP 7.3 -> upgrade -нарушение зависимостей;
сам прикручивал apt-get к ASP 7.3 & 9 - при попытке обновления rpm, glibc , gcc, kernel - нарушение зависимостей/падение системы;
Все это приходилось разруливать ручками. Правда, может ручки кривые, конечно.
Особенно весело было, когда обновилась версия rpm.
В результате, пришлось отказаться от upgrade, а "опасные" на мой взгляд пакеты устанавливать по отдельности, ручками.

И представьте мое удивление, когда делая emerge glibc (gcc, прочие базовые пакеты) я не имею геморроя!

[xorader]

2 madskull: именно ! полчаса назад сказал почти тоже... только мата было много (воспоминания нахлынули). Вообщем бороться с софтом я закончил после перехода на gentoo сейчас занимаюсь более интересными вещами

[t.t]

Ребят, у меня складывается такое впечатление, что никто не слышал об yum. Равно как и apt-get под ту-же Федору. И в первой и во второй программе имеется такая опция, которая обзывается UPGRADE, т.е. банальное ОБНОВЛЕНИЕ пакетов, которые установлены. Абсолютно никто не заставляет запускать тот-же yum с опцией UPDATE, когда обновляются и УСТАНАВЛИВАЮТСЯ ВСЕ новые пакеты, которые есть на репрозитории пакетов, т.е. производится ПОЛНАЯ установка дистрибутива. Обнови существующие и радуйся жизни.

↑

По-моему, здесь уже достаточно чётко говорилось, что rpm не нравится многим не за отсутствие/наличие возможности апдейта, а за зависимости. Мне вот, например, тот же apt-get в Альте выдал полторы сотни метров "проапдейтить", включая неудовлетворённые зависимости; а когда я руками посмотрел, что из этого мне действительно нужно, осталось метров 30-40.

[Shurik]

to madskull

Докладаю честно и откровенно. Обновлял систему с ASPLinux9.0 до ASPLinux9.2 Обновлял так:
- Скопировал ВСЕ пакеты с 3-х компактов на другой хард. Создал там каталог headers. Прописал в конфиге yum дополнительную секцию, где указал путь к каталогу с пакетами. Далее:
# yum-conf off updates
# yum-conf off mastersite
# yum-arch /mnt/xxxxx - полный путь до каталога с пакетами(headers он находит сам и прописывает туда всё, что нужно.)
# yum upgrade
При попытке обновления мне было заявлено, что отсутствует библиотека (сейчас уже не помню точно - какая). Глянул - уже стоит этот пакет и есть такая библиотека.Удалил к чертям этот пакет. Запустил снова. Теперь уже ничего не гавкалось, yum определил зависимости и объявил, что можно обновлять. Просмотрел пакеты, что по мнению yum требуют обновления. Ничего лишнего не обнаружил. Запустил его обновлять и пошел гулять. Когда пришел уже всё было готово. Перегрузил тачку и получил уже ASPLinux9.2 со всеми документами и настройками.
P.S. В yum имеется такой косяк - если загружаешься не со стандартного ядра(т.е. которое было при установке), а с пересобранного (к примеру версия+custom), то этот гад вообще в какие-то дебри лезет и начинает предлагать установить то, чего совеншенно не требуется. или может вообще заявить, что для такой-то проги нужны исходники, а тебя их нет, как впрочем и самого пакета с исходниками.

[Shurik]

P.S.S. Забыл добавить - обновлял так потому, что в инсталлере 9.2 опция "обновить" отсутствует, как класс! И именно по причине того, что обновлял систему с помощью yum я пропустил очень занимательные танцы с бубном при "чистой" установке 9.2

[xorader]

хехе... звучит красиво... у вас никогда база rpm не отмирала сама собой ? yum не глючил ? не надоедало определять что изменилось в /etc ? у меня тут один раз yum умер окнчательно вместе с rpm когда я удалил /lib/modules/.. текущего ядра... я так и не понял что yum'у так вдруг жизненно необходимо нужно было когда он намертво повисал при любом действии с ним. Не..., я конечно понял, но зачем так сделали ? :-\
Вообщем вы счасливчик раз у вас проблем особых не было с yum. Я ничего против него не имею так как был очень доволен им в своё время !!! Но при выборе между emerge и yum я любому посоветую первое как наиболее мудрое и стабильное решение!!!!

[zenwolf]

хехе... звучит красиво... у вас никогда база rpm не отмирала сама собой ? yum не глючил ? не надоедало определять что изменилось в /etc ? у меня тут один раз yum умер окнчательно вместе с rpm когда я удалил /lib/modules/.. текущего ядра...  я так и не понял что yum'у так вдруг жизненно необходимо нужно было когда он намертво повисал при любом действии с ним. Не..., я конечно понял, но зачем так сделали ? :-\ 
Вообщем вы счасливчик раз у вас проблем особых не было с yum. Я ничего против него не имею так как был очень доволен им в своё время !!! Но при выборе между emerge и yum я любому посоветую первое как наиболее мудрое и стабильное решение!!!!

↑

А я бы выбрал ещё более мудрое - порты во FreeBsd

Вобще про установку вы меня несовсем поняли ,я имел ввиду не сервера , а машины
для юзеров

[Topper]

я достаточно регулярно делаю apt-get dist-upgrade в своем Альте. изначально обновлял с мастера 2.2 до среза Сизифа за январь этого года... никаких проблем вообще не вызвало. все заработало с ходу и работает до сих пор. вот с обновлением glibc пришлось повозиться. то есть, сам-то он обновился без вопросов, а вот рпм после этого пахать отказался... пришлось лапками, используя предусмотрительно оставленный разработчиками альтернативный вариант, ставить свежую версию рпма...

[Shurik]

По-моему, здесь уже достаточно чётко говорилось, что rpm не нравится многим не за отсутствие/наличие возможности апдейта, а за зависимости. Мне вот, например, тот же apt-get в Альте выдал полторы сотни метров "проапдейтить", включая неудовлетворённые зависимости; а когда я руками посмотрел, что из этого мне действительно нужно, осталось метров 30-40.

↑

Я нисколько не возражаю, что тот-же yum, или apt-get тащат кучу пакетов при update. Но они-же тащат минимальное количество при upgrade. Равно, как и тот-же Gentoo. emerge так-же тащит кучу патчей, программ и программочек при том-же обновлении, или установке! И не стоит говорить, что это не так! Практически разница сводится к тому, что в Gentoo - это отдельные файлики, а в rpm - уже собранные и пропатченные. И ещё, в rpm уже есть совместимость и с тем-же KDE и с Gnome. В Gentoo её просто нет. Поставь себе в Gentoo и KDE и Gnome(хотя-бы даже для сравнения одного с другим) и будешь приятно удивлён - сколько тот-же хвалёный emerge тащит всего с собой! НИЧУТЬ не меньше, чем тот-же yum, или apt! Другой вопрос, что в Gentoo ты ставишь по выбору - или KDE, или Gnome, или ещё что, но точно так-же ты можешь поставить и в rpm не всё, а выборочно!

[xorader]

> И ещё, в rpm уже есть совместимость и с тем-же KDE и с Gnome

просветите меня, что это за совместимость такая ? я что то не догоняю, товарищи ?

> В Gentoo её просто нет.

и слава богу ))

> ... сколько тот-же хвалёный emerge тащит всего с собой

Он тащит ровно столько - сколько нужно. Он тащит исходники. Чему удивляться ?

> НИЧУТЬ не меньше, чем тот-же yum, или apt

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

> .. можешь поставить и в rpm не всё, а выборочно

только при помощи emerge это быстрее и наглядней. Спорить с этим фактом не будем ?

[Shurik]

просветите меня, что это за совместимость такая ? я что то не догоняю, товарищи ?

↑

Просвещаю
При сборке rpm пакета разработчик просто не знает - что стоит у тебя, есть та, или иная библиотека, в какой GUI-среде ты обитаешь - Gnome? KDE? Или ещё в чём?
Пример:
У тебя rpm дистрибутив. При начальной установке ты решил, что KDE тебе ни к чему - будешь пользоватся Gnome. Но! Разработчик rpm пакета об этом абсолютно не осведомлён! Он собирает свой пакет, что-бы тот мог работать и в Gnome и в KDE. Ставит зависимости.
- Библиотека А не может работать в KDE без библиотеки Б.
- Библитека Б имеется в пакете "Б"
- пакет "Б" не может работать, если нет библиотеки В, которая имеется в пакете "В"
Результат:
- Тебе выдаётся предупреждение, что для удовлетворения зависимостей тебе просто необходимы пакеты KDE "Б" и "В".
Так-ли это на самом деле? Действительно-ли тебе нужны библиотеки KDE "Б" и "В"? Нисколько не сомневаюсь, что копатся по каждому конкретному случаю ни у кого нет ни малейшего желания. Но! Это совершенно не исключает возможности поставить только исходный пакет с опцией --nodeps и не ставить пакеты "Б" и "В". Будет в таком случае работать программа в Gnome? Да! Ставил-ли ты в таком случае другие пакеты по зависимостям? Нет!
Итог:
- Ты поставил пакет, но не стал тянуть не нужные тебе пакеты из KDE.

[Golden]

Просвещаю
При сборке rpm пакета разработчик просто не знает - что стоит у тебя, есть та, или иная библиотека, в какой GUI-среде ты обитаешь  - Gnome? KDE? Или ещё в чём?
Пример:
У тебя rpm дистрибутив. При начальной установке ты решил, что KDE тебе ни к чему - будешь пользоватся Gnome. Но! Разработчик rpm пакета об этом абсолютно не осведомлён! Он собирает свой пакет, что-бы тот мог работать и в Gnome и в KDE. Ставит зависимости.
- Библиотека А не может работать в KDE без библиотеки Б.
- Библитека Б имеется в пакете "Б"
- пакет "Б" не может работать, если нет библиотеки В, которая имеется в пакете "В"
Результат:
- Тебе выдаётся предупреждение, что для удовлетворения зависимостей тебе просто необходимы пакеты KDE "Б" и "В".
Так-ли это на самом деле? Действительно-ли тебе нужны библиотеки KDE "Б" и "В"? Нисколько не сомневаюсь, что копатся по каждому конкретному случаю ни у кого нет ни малейшего желания. Но! Это совершенно не исключает возможности поставить только исходный пакет с опцией --nodeps и не ставить пакеты "Б" и "В". Будет в таком случае работать программа в Gnome? Да! Ставил-ли ты в таком случае другие пакеты по зависимостям? Нет!
Итог:
- Ты поставил пакет, но не стал тянуть не нужные тебе пакеты из KDE.

↑

Верно. Но именно в разруливании таких зависимостей преимущества Source-based налицо. То, что вы делаете, по отношению к rpm является hack'ом, потому как это просто принудительно заблокированные зависимости. И есть неплохой шанс, что что-нибудь действительно вам нужное вы упустите. А чтобы не упустить - приходится ставить и библиотеки KDE из вашего примера. Потому как не всегда ситуация столь прозрачна (некоторые библиотеки нужны вообще непонятно кому и никогда не угадаешь, кто ее использует).
А при сборке из исходников, вы поддержку ненужных вам фич (в вашем примере, KDE) попросту не компилируете. И, соответственно, из сети не тянете.

[Vladislav]

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

[Shurik]

Верно. Но именно в разруливании таких зависимостей преимущества Source-based налицо. То, что вы делаете, по отношению к rpm является hack'ом, потому как это просто принудительно заблокированные зависимости. И есть неплохой шанс, что что-нибудь действительно вам нужное вы упустите. А чтобы не упустить - приходится ставить и библиотеки KDE из вашего примера. Потому как не всегда ситуация столь прозрачна (некоторые библиотеки нужны вообще непонятно кому и никогда не угадаешь, кто ее использует).
А при сборке из исходников, вы поддержку ненужных вам фич (в вашем примере, KDE) попросту не компилируете. И, соответственно, из сети не тянете.

↑

Абсолютно никаких возражений!
Я к чему клоню? В rpm имеются пакеты. собранные под определённую архитектуру(i386 - athlon и т.д.) Но я ни разу не видел пакета собранного исключительно под KDE, или Gnome. Да, в Gentoo большая гибкость при установке, но плата за это - всеобщее компилирование всего и вся. А грубо говоря - потеря времени. rpm - быстрая установка(обновление) всего и вся, но плата за это - установка дополнительных(очень часто вообще ненужных пакетов) пакетов, и как следствие - более больший объём при обновлении(установке).

Теперь вопрос - означает-ли это, что rpm - тупиковая ветвь в развитии Linux?

[Golden]

Я бы так категорично не говорил. И в этом топике и в других rpm позиционируется как средство для быстрой установки софта. Однако, на практике, я все больше знаю админов, которые ставят себе локальный Gentoo-репозитарий, из него компилируют бинарники с поддержкой софта, который используется в этой компании (как правило, это что-то одно из DE, одно из броузеров и т.п.) и затем с большим успехом все это расставляют по компам, причем, зачастую, даже не вставая с рабочего места. Так что и в этом отношении преимущества пакетных дистрибутивов уже спорны. И уж очень спорно преимущество rpm. Я бы все-таки выбрал deb - в нем зависимости сделаны более гибко и логично, их легче разруливать. Да и apt-get для Debian'a родной, а не прикрученный сбоку, как для rpm.

[Shurik]

Я тоже категорично не утверждаю, что rpm - это шибко здорово, но как один из вариантов он вполне имеет право на существование. Мало того, крайне мало найдётся энтузиастов, которые решили скомпилить себе тот-же ОО в Gentoo и часов через 5-6 у них вылетела компиляция с указанием ошибки (лично у меня такое было). После этого найти причину, поправить её и ещё раз запустить компиляцию. Достаточно много народа согласится со мной, что в данном случае поставить rpm пакет, пусть даже и с 3-5 ненужными зависимостями, за 10 минут намного предпочтительнее.

[edoc_modnar]

Просвещаю
При сборке rpm пакета разработчик просто не знает - что стоит у тебя, есть та, или иная библиотека, в какой GUI-среде ты обитаешь  - Gnome? KDE? Или ещё в чём?
Пример:
У тебя rpm дистрибутив. При начальной установке ты решил, что KDE тебе ни к чему - будешь пользоватся Gnome. Но! Разработчик rpm пакета об этом абсолютно не осведомлён! Он собирает свой пакет, что-бы тот мог работать и в Gnome и в KDE. Ставит зависимости.
- Библиотека А не может работать в KDE без библиотеки Б.
- Библитека Б имеется в пакете "Б"
- пакет "Б" не может работать, если нет библиотеки В, которая имеется в пакете "В"
Результат:
- Тебе выдаётся предупреждение, что для удовлетворения зависимостей тебе просто необходимы пакеты KDE "Б" и "В".
Так-ли это на самом деле? Действительно-ли тебе нужны библиотеки KDE "Б" и "В"? Нисколько не сомневаюсь, что копатся по каждому конкретному случаю ни у кого нет ни малейшего желания. Но! Это совершенно не исключает возможности поставить только исходный пакет с опцией --nodeps и не ставить пакеты "Б" и "В". Будет в таком случае работать программа в Gnome? Да! Ставил-ли ты в таком случае другие пакеты по зависимостям? Нет!
Итог:
- Ты поставил пакет, но не стал тянуть не нужные тебе пакеты из KDE.

↑

Постой, чего-то здесь не чисто... Ну и что? --nodeps - варварский способ, это как rm -r / ^_^. А ты слышал, что в Gentoo есть файлик make.conf, в котором есть такая переменная USE. Так вот, все, что ты описывал, делается так:

EXPORT USE = "-qt -kde"
emerge softx

Вот, собсно и все... Прога собирается без поддержки КДЕ, что нам и надо. Да и был бы portage такой бесполезной штукой, ни за что не портировали бы его в Free/OpenBSD (там и так есть порты). Зачем? http://unix.ginras.ru/freebsd/mini-howto/f...and-gentoo.html
:lol:

[Shurik]

to random_code

Я слышал и знаю, что в Gentoo имеется файлик make.conf. Дальше что?
Я пишу вроде как на русском языке - "...У тебя rpm дистрибутив..." У нас что, в rpm-дистрибутивах уже emerge появился? Отстаю от жизни.............

[edoc_modnar]

to random_code

Я слышал и знаю,  что в Gentoo имеется файлик make.conf. Дальше что?
Я пишу вроде как на русском языке - "...У тебя rpm дистрибутив..." У нас что, в rpm-дистрибутивах уже emerge появился? Отстаю от жизни.............

↑

Я просто показал, как это в Gentoo делается... Намного легче, да и правильнеее, не так ли?

[Shurik]

to random_code

Я слышал и знаю,  что в Gentoo имеется файлик make.conf. Дальше что?
Я пишу вроде как на русском языке - "...У тебя rpm дистрибутив..." У нас что, в rpm-дистрибутивах уже emerge появился? Отстаю от жизни.............

↑

Я просто показал, как это в Gentoo делается... Намного легче, да и правильнеее, не так ли?

↑

Я про Фому, а ты - про Ерёму.
Я про то, что разработчик rpm просто ОБЯЗАН заботится о том, что-бы его пакет нормально работал и в KDE и в Gnome, а ты мне про то, что в Gentoo можно установить тот-же пакет, но не ставя по зависимостям отсутствующих приложений!

[Warderer]

Я про Фому, а ты - про Ерёму.
Я про то, что разработчик rpm просто ОБЯЗАН заботится о том, что-бы его пакет нормально работал и в KDE и в Gnome, а ты мне про то, что в Gentoo можно установить тот-же пакет, но не ставя по зависимостям отсутствующих приложений!

↑

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

[Vladislav]

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

↑

У меня такая потребность возникает крайне и крайне редко, но при ее возникновении решением является:
apt-get source ....
dpkg-buildpackage
И добавление этого пакета репозиторий.

[Shurik]

Остапа понесло.............
Ребята, Вам не кажется, что это всё немного не о том. Мы здесь не обсуждаем достоинства-недостатки того, или иного дистрибутива.
Позволю себе напомнить всем, что название данного топика:
Пакетные дистрибутивы - тупиковая ветвь?
Другими словами - имеют пакетные дистрибутивы право на жизнь? Или он всё-таки загнутся под напором портовых дистрибутивов?
Я пытаюсь доказать, что пакетные дистрибутивы имеют право на жизнь. Вы мне пытаетесь доказать, что в Gentoo установка пакетов намного оптимальнее.
Давайте тогда заведём отдельный топик, типа:
RPM - Port - достоинства и недостатки.

[zenwolf]

Остапа понесло.............
Ребята, Вам не кажется, что это всё немного не о том. Мы здесь не обсуждаем достоинства-недостатки того, или иного дистрибутива.
Позволю себе напомнить всем, что название данного топика:
Пакетные дистрибутивы - тупиковая ветвь?
Другими словами - имеют пакетные дистрибутивы право на жизнь? Или он всё-таки загнутся под напором портовых дистрибутивов?
Я пытаюсь доказать, что пакетные дистрибутивы имеют право на жизнь. Вы мне пытаетесь доказать, что в Gentoo установка пакетов намного оптимальнее.
Давайте тогда заведём отдельный топик, типа:
RPM - Port - достоинства и недостатки.

↑

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

2random_code
перенос портежей в FreeBSD имеет пока чисто экперементальный
характер (вобще сами портеже имеют в предке порты BSD -систем - это
у них была первично придумана сия система а не в linux ).

[madskull]

Остапа понесло.............
Ребята, Вам не кажется, что это всё немного не о том. Мы здесь не обсуждаем достоинства-недостатки того, или иного дистрибутива.
Позволю себе напомнить всем, что название данного топика:
Пакетные дистрибутивы - тупиковая ветвь?
Другими словами - имеют пакетные дистрибутивы право на жизнь? Или он всё-таки загнутся под напором портовых дистрибутивов?

↑

Так уже ответили же ж:

За Gentoo не скажу, я его не пробовал; но вот в deb, например, зависимости хотя и "играют отнюдь не последнюю роль", но они гораздо гибче и продуманнее, вследствие чего тот же mc тащит за собой намного меньше, чем в rpm. Но даже несмотря на это я не считаю rpm тупиковой ветвью, хотя бы потому, что они уже очень хорошо раскручены.

↑

Хотя бы потому, что Ред Хат довольно сильный игрок, а отказываться от РПМ и переделывать идеологию своих дистров они врядли будут. То же самое касается и Мандраков, и Дебианов.

[xorader]

Я про то, что разработчик rpm просто ОБЯЗАН заботится о том, что-бы его пакет нормально работал и в KDE и в Gnome, а ты мне про то, что в Gentoo можно установить тот-же пакет, но не ставя по зависимостям отсутствующих приложений!

Очень интересно Shurik, вы представляете вообще, что программа просто не может по определению работать без недостающих ей компонентов. Да, можно написать программу которая на лету определяет недостаток некоторых компонентов и отключает соотв-ую функциональность в себе. Но таких программ еденицы, а уж чтобы переделать программу в сторону динамического связывания - это нужно много времени, а порой переписывание софта с нуля -- вы утверждаете что RedHat этим занимается ? <_< <_< <_<

Теперь по поводу потери времени:
разделим время на следующие компоненты:
1) время затраченное администратором на установку софта (то есть время которое он затратил на обдумывание и набор соотв-их команд для установки)
2) машинное время
3) время на постинсталяционную конфигурацию

Так вот по первому пункту gentoo вне конкуренции (особенно при разруливании зависимостей и прочая прочая)!
По второму пункту - я на экран тупо не смотрю в момент компиляции, а занимаююсь полезными вещами
3) IMHO(!), и тут gentoo впереди

Вывод: время администратора отнимает меньше gentoo. В результате при установки и поддержки большого кол-ва серверов и прочая прочая - при использовании gentoo, администратор успевает сделать больше!!!

[Shurik]

to xorader
Опять-же, давай заведём отдельный топик и там всё это обсудим. Ты приведёшь свои аргументы - я - свои.