Что глупости? Что мне самому прид╦тся следить за мной же установленными пакетами? Или apt/dpkg будет сам тащить новые версии, применять патчи, компилить и ставить вместо меня, решать проблемы которые могут при этом возникнуть? При условии, разумеется, что этот пакет не часть дистрибуции. Если этого не делают авторы дистра или кто-то ещ╦ (а компиляция и установка своих пакетов как раз предполагает, что никто другой этого не делает) - то это прид╦тся делать мне, или я настолько отстал от жизни и APT/dpkg представляют навороченный AI, заменяющий сисадмина? Да, я могу автоматизировать установку и обновление на нескольких хостах, но следить за текущестью вс╦-таки прид╦тся.
В конце концов, зачем придумали дистрибутивы и их строителей? Что бы пользователи (пусть даже и продвинутые) сами вс╦ ставили, ручками? А работать когда?

Не надо путать теплое с мягким. Полагаетесь на дистростроителей - используйте автоматическое обновление. Ставите что-то свое - несите ответственость за свои действия. У всех дистрибутивов своя политика и похоже ни одна вас не удовлетворяет. Тогда делайте сами. Глупо предьявлять претензии людям, которые вам ничего не должны.
---
В оптический пpицел мы смотpим с оптимизмом!

Вы с матерьялом ознакомились? Тяжело спорить о вкусе устриц с человеком, который их не ел.

Да.
----

Да. ***И не высасывайте сложности из пальца, там где их нет.
----

Нет. ***.
----

Незнаю. Учите матчасть, прежде чем начинать спорить.
----

С этим вопросом в ДК, там такие темы *за мир во вс╦м мире* любят.

Глупо предьявлять претензии людям, которые вам ничего не должны.
Я никому ничего не предъявлял. Я всего лишь спросил, есть ли что-то готовое, удовлетворяющее моим требованиям, что бы мне самому ничего не пришлось делать. Да, я высказался в духе "хреново они работают, раз нет" - но это не претензия, а (если можно так сказать) "риторическая жалоба". Вот и вс╦. Меня же завалили советами на тему "можно взять апельсин, срезать с него шкурку, покрасить - и получится яблоко"

Учите матчасть, прежде чем начинать спорить.
Да ну? Ну расскажите мне способ, которым APT/dpkg способен _сам_ взять новую версию чего-то (в исходном виде), применить патч, откомпилить, обнаружить что нехватает какой-то либы (или хидера), взять то чего не хватает, попытаться его скомпилить или поставить (с риском напороться на аналгичную проблему), повторять процесс до победного конца, в финале выдавая готовый к дистрибуции пакет. Увы, мне такое чудо природы найти не удалось - все _проблемы_ возникающие при компиляции решаются только ручками, и APT/dpkg их не решает.
Даже если предположить, что я пропишу где что брать и что с ним делать - вопрос решения потенциальных проблем остается открытым, и в итоге, если таковые возникнут (а они возникнут, это только вопрос времени), решать их прид╦тся мне самому - как раз то чего я делать не хочу (сколько раз мне про это нужно сказать, что бы не получать советов "сделай ручками" и "вс╦ решается при желании"?).
Так что давайте не будем про матчасть - AI, способный заменить человека в рассматриваемом случае, ещ╦ не создан, иначе бы у меня не было проблемы, в связи с которой я задал вопрос.

Винегрет из набора фраз на тему. Сформулируйте ч╦тко что Вы хотите, тогда я расскажу как это сделать.
----

Облость предположений меня мало интересует.
----

Только так и никак иначе, нравиться Вам это или нет.
----

Вам здесь уже ни раз сказали в ч╦м Ваша проблема.

Вы забыли включить злобных инопланетян и происки Ктулху.
---
Внебрючные отношения.

> Там нет менеджера пакетов в нормальном виде.
Ага, как же, нет, с чего ты взял? Система называется portage.
> Не существует _автоматического_ способа просчитать зависимости пакета, который существует только в виде исходников.
Пакета или программы? Если говорить о программах, то для собственных программ это не нужно, а если о тех, что существуют в природе для Linux, они все есть в дереве портежей в виде пакетов. Portage позволяет посчитать зависимости пакетов _автоматически_.
> К тому же, я уже говорил, это плохая идея - компилировать пакеты каждый раз, когда они нужны, вместо того что бы поставить готовый бинарник.
Portage позволяет работать и с бинарными пакетами. Только это никому не нужно, кроме случая, когда пакеты собираются сразу для всей сетки на одном компьютере. Насч╦т "плохой идеи": барин - хозяин, но, в любом случае, обновление софта полностью подда╦тся автоматизации и может проходить полностью без участия человека.
> где все зависимости отточены
Чудной человек - вон, в Слаке ихний рулевой "отточил" зависимости от Гнома. Теперь проблемы с Гномом там нет как класса. Как и самого Гнома. Нафиг надо, такие отточенные зависимости - вот, скажи, с чем линковать mc, к примеру, с ncurses или с slang должны дистростроители твоего гипотетического дистрибутива? (обе библиотеки для консольной отрисовки умеет использовать mc).
>> а если охота со свежим софтом играть, то на рабочем сервере это не делают
>Да ну?
Ну да. Это для тебя новость? Хочешь поиграть с одной занимательной программой длинной в одну строчку на Perl- е на сво╦м сервере?
Там где _работают_ любое изменение окружения проходит крайне консервативно. И предварительно тесты проводят на тестовой машине, чтобы не угробить рабочую систему, если что-то пойд╦т не так, и причина всегда должна иметься, чтобы что-то менять, а не просто от балды в виду выхода новой версии. Все пионерские подвиги с тестированием новых версий программ на рабочих машинах оканчиваются обычно увольнением. Если контора, конечно нормальная, а не шаражка какая.
Как ты думаешь, почему ещ╦ живо ядро ветки 2.4.хх, ведь, есть же более архитектурно правильная ветка 2.6.xx? Или почему PHP5 нифига не рулит до сих пор, а везде стоит PHP4, который просто издевательство над программистом? Или почему жива первая ветка Apache?

> Да ну? Ну расскажите мне способ, которым APT/dpkg способен _сам_ взять новую версию чего-то (в исходном виде), применить патч, откомпилить, обнаружить что нехватает какой-то либы (или хидера), взять то чего не хватает, попытаться его скомпилить или поставить (с риском напороться на аналгичную проблему), повторять процесс до победного конца, в финале выдавая готовый к дистрибуции пакет. Увы, мне такое чудо природы найти не удалось - все _проблемы_ возникающие при компиляции решаются только ручками, и APT/dpkg их не решает.
А оно не надо. Если надо безгимморойно собрать программу, при отсутствии нужных зависимостей, есть auto-apt:
auto-apt run ./configurе
всё необходимое для сборки автоматически доставится. Ну, а потом checkinstall какой-нибудь, который делает пакеты.

Сформулируйте ч╦тко что Вы хотите, тогда я расскажу как это сделать.
OK, попытка номер... эээ... большой. Есть система с кучей пакетов, многие из которые или устарели, или не содежат того что нужно, а многие просто лишние. При этом, система построена на PM (неважно, RPM или DPKG или хз что ещ╦), то есть просто заменит/удалить нужное/ненужное приводит к развалу и шатанию (с точки зрения PM). Задача: Имея такую систему, удалить вс╦ ненужное, но так, что бы PM не считал это нужным (а он это делает). Заменить ряд пакетов новыми (современными) версиями и поддерживать их в текущем виде (security etc), опять-таки, не нарушая спокойной жизни PM, если добавится что-то, не знающее о новой версии. Размножить это вс╦ на N компов. Ну и самое главное - это вс╦ должно занимать не более 15 минут в неделю, желательно без участия человека вообще. Особые условия: Gentoo/Debian/Ubuntu/Slackware не подходят по идейным (необсуждаемым) соображениям.
Вам здесь уже ни раз сказали в ч╦м Ваша проблема.
Да-да, я знаю - моя проблема в том, что я родился

Вы забыли включить злобных инопланетян и происки Ктулху.
Не-а. Я забыл, какого хрена хорошо известный djb по прежнему не включает <errno.h> в своих (весьма полезных, кстати, тулзах), в то время как это необходимо во всех современных дистрах линуха (иначе не работает, т.е. не компилируется или не собирается). Это похлеще инопланетян будет... А казалось бы - мелочь, да...

Если говорить о программах, то для собственных программ это не нужно, а если о тех, что существуют в природе для Linux, они все есть в дереве портежей в виде пакетов. Portage позволяет посчитать зависимости пакетов _автоматически_.
А чем собственные программы отличаются от несобственных, а? С этой точки зрения? У них тоже бывают зависимости А вот как portage _сам_ посчитает зависимости, имея исходники ранее _неизвестного_ приложения - это для меня тайна, покрытая мраком. Иногда даже ручками (глазками) это тяжко сделать. Не говоря уже о случаях, когда зависимости могут быть обязательными, а могут быть опциональными.
Portage позволяет работать и с бинарными пакетами. Только это никому не нужно, кроме случая, когда пакеты собираются сразу для всей сетки на одном компьютере.
"никому"? Это нужно всем, кто не хочет заморачиваться с компиляцией всего из исходников. Какой в этом смысл? Особенно когда речь про сетку.
обновление софта полностью подда╦тся автоматизации и может проходить полностью без участия человека
Ну-ну... Зависит от софта... Иногда новый софт _слегка_ несовместим со старым, или с чем-то ещ╦, в общем, вс╦ зависит. Автоматизации легко (сравнительно) поддается только обновление, которое было приготовлено кем-то извне, и то, бывают проблемы (например, когда "новой" версией заменяется установленный вручную пакет, той же версии но с другими опциями скомпилированный - и вс╦ ид╦т нафиг).
Чудной человек - вон, в Слаке ихний рулевой "отточил" зависимости от Гнома. Теперь проблемы с Гномом там нет как класса. Как и самого Гнома.
Это наш человек Ибо гном мастдай Ну зачем такой монстр нужен, а?
вот, скажи, с чем линковать mc, к примеру, с ncurses или с slang должны дистростроители твоего гипотетического дистрибутива?
Я бы предпочел две версии, если честно Хотя, с учетом размера slang, я бы не возражал против только одной. Но в мо╦м гипотетическом дистрибутиве пакеты бы требовали то, чего им не нужно для работы, и не ругались на опциональные компоненты (типа поддержки TTF в случае установки PHP).
Хочешь поиграть с одной занимательной программой длинной в одну строчку на Perl- е на сво╦м сервере?
Со мной такие штучки не проходят А чайники смело вводят даже "rm -rf / &". Но я говорил не про эксперименты такого типа, а про _работающие_ и _проверенные_ вещи, просто новые (примеры см. раньше).
Там где _работают_ любое изменение окружения проходит крайне консервативно.
Спасибо, я в курсе. Я и не говорю об изменениях - я говорю об установке _современного_ софта, и его использовании, а не смене пакетов с разной major version на живой системе.
Как ты думаешь, почему ещ╦ живо ядро ветки 2.4.хх, ведь, есть же более архитектурно правильная ветка 2.6.xx?
Потому что некоторые свято верят, что оно стабильней и надежней, чем 2.6 (совершенно зря - это верно только в частных случаях). Но в большинстве приложений эта разница неощутима, а некоторым нужны как раз фичи из 2.6, при этом оно вполне стабильно. И PHP5 вполне рулит, просто под него мало приложений, и он частично несовместим (не на уровне стабильности) с PHP4. Первый же апач жив условно - его мало кто использует. Но если поискать - то можно найти консерваторов, у которых ещ╦ стоит ядро 1.2, Perl 4 etc :)

понимаешь какая штучка выходит! дело в том что таких дистрибутивов не существовало и существовать не будет.

из этого всего хотелось бы подчеркнуть что в твоей формулировке присутствуют эллементы выражающие ТВОИ желания и просимулировать их не представляется возможным, потому как сначала необходимо знать чего тебе хочется. это еще пол-беды выразить, что тебе необходимо. вся беда заключается в том как это передать системе.
без рукоприкладства здесь никак не обойтись и я вижу всего лишь 3 варианта в твоей ситуации:
1. взять простенький попсовый дистрибутивчик типа канотикса или убунту и настроить его после установки под себя
2. взять по сложнее дистрибутивчик типа генту, слаки и настроить как тебе это нужно.
3. построить дистрибутивчик самому на основе LFS http://www.linuxfromscratch.org/. один раз настроил ВСЕ как тебе нужно, ВКЛЮЧАЯ пакетменеджмент и про все забыл.
но если посмотреть в общем и целом то время рукоприкладства везде одинаково просто распределяется по разному и выражается в раззной форме.
советую конкретно сформулировать проблему и расписать ее по пунктам а после смотреть что из существующего тебе подходит.
удачи в поиске!

то еще пол-беды выразить, что тебе необходимо. вся беда заключается в том как это передать системе.
Ещ╦ раз повторюсь - я знаю как это передать и сделать, я просто _не хочу_ этого делать. Я надеялся, что кто-то это уже сделал за меня - напрасно, как оказалось.
советую конкретно сформулировать проблему и расписать ее по пунктам а после смотреть что из существующего тебе подходит.
Если из моих требований убрать занимаемое пространство и не всегда понятные зависимости - то мне подходит Fedora Core. Видимо, на этом и остановлюсь... Из всего спектра обсужденных дистров мне вс╦-таки (с административной и прикладной точки зрения) ближе RH-like системы.
Хотя в свое время я был фанатом Slackware и так же рьяно отстаивал точку зрения, что вс╦ нужно делать ручками... И не понимал тех, кто не хотел или не умел этого делать... Точно также не воспринимал их аргументы... А потом я вырос

> А чем собственные программы отличаются от несобственных, а? С этой точки зрения?
Ну, это же просто: для работы на данном компе собственной программы написанной тут же, ничего доставлять не надо, вс╦ уже есть (в процессе написания программы было поставлено).
> А вот как portage _сам_ посчитает зависимости, имея исходники ранее _неизвестного_ приложения - это для меня тайна, покрытая мраком.
Portage не знаю пока, не интересовался в силу ненадобности, есть ли что-то подобное auto-apt и что вообще есть в области автоматической генерации ебилдов (файлов в которых расписано вс╦ о пакете) - поинтересуюсь сегодня, про APT же я написал выше.
> Ну зачем такой монстр нужен, а?
Мне лично Гном не нравится этим же самым, но, это не мой подход - решать за пользователя, что ему нужнее. Я за свободу выбора.
> "никому"? Это нужно всем, кто не хочет заморачиваться с компиляцией всего из исходников. Какой в этом смысл? Особенно когда речь про сетку.
Я имел в виду пользователей Gentoo. Хотел сказать только, что только в тех наиредчайших случаях, когда Gentoo используют в сетке, пользуются распространением пакетов в бинарном виде после сборки их на одном компе.
> и то, бывают проблемы (например, когда "новой" версией заменяется установленный вручную пакет, той же версии но с другими опциями скомпилированный - и вс╦ ид╦т нафиг).
Ну, кто же вручную пакеты ставит? Это путь к хаосу и Слаке. Нафиг-нафиг. Всегда пакет сначала изготовить. Вот, кстати, yum не умеет маскировать, насколько я понял, пакеты от нежелательного апдейта. В Portage же, помимо маскирования, можно персоналльно для конкретных пакетов указать USE флаги.
> Но если поискать - то можно найти консерваторов, у которых ещ╦ стоит ядро 1.2, Perl 4
Когда система на 100% выполняет свои функциональные обязанности, изменять е╦ смысла нет.

да хотя бы федора ... мне лично тоже оч нравиться :)

Читал эту хохму как Патрик не асилил гном, честно говоря очень удивился.

В слацкваре уже давно не нужно делать ручками более того, что и в других дистрибутивах.
---
...Звеpей на эскалатоpе деpжите за клюв! (2:5020/423.39)

Просто была пара независимых проэктов, которые собирали гном для слаквари + дествительно жуткие зависимости внутри кучи гномьих библиотек. Все-таки он один работает над дистрибутивом. Вот и решил избавится от монстрика. К тому же с выходом 2.0 гном потерял довольно много приверженцев. Очень уж тормозным и неудобным он казался после 1.4.
---
Истиннyю ценy живого общения понимаешь, глядя на счета от пpовайдеpа.

Ну если один работает над дистром (не знал) то понятно. К примеру в убунте гном очень вылизанный, уже многими призна╦ться что гном в убунте лутший. Они как-то с самого начала выбрали его в качестве основного десктопа и видимо уже неплохо "набили руку" на н╦м. Т.е. это пример что если захотеть, довести до ума гном не проблема и было непонятно почему этого не смогли сделать в Слакваре. Но если он один работает, то вопросов нет.