На сайте «Компьютерры» опубликовано интервью с разработчиком Deepsolver

Почему бы не сделать так в линуксе?

Потому что никому из тех, кто может сделать, это не нужно.

Я буду утверждать, что из одного банального примера можно делать только не менее банальный вывод. Вроде «для простых случаев apt-get вполне справляется с работой».

А в сложных случаях ВСЕГДА требуется вмешательство человека, а не «умной» автоматики. На то они и сложные.

Всем. Пруф - https://plus.google.com/u/0/105869626066338837813/posts/9PjpcqoSWy6

И ? В #26915 описана нехватка зависимостей для раскрытия некоторых макросов. Криминал где ?

Максимум, в чем их можно обвинить - это в NIH syndrome.

Просто к понятию «русский разработчик» традиционно мало доверия. Хотя альтовцы в целом неплохо работают. Причин считать, что они эпично зафейлятся, кажется, действительно нет.

В несоблюдении принятых полиси. Чего уж говорить про непринятые?

Почему бы не сделать так в линуксе? Или это технически сложно, нужно всю о/с перекурочить?

Совершенно не сложно. Но не нужно.

В несоблюдении принятых полиси. Чего уж говорить про непринятые?

Кто цитату привёл ?

«Пакет rpm-macros-%name не должен иметь сторонних зависимостей, кроме тех, которые необходимы для раскрытия содержащихся в нём макросов.»

Эта зависимость, судя по багу, была нужна.

Нет. Читай внимательнее.

А в сложных случаях ВСЕГДА требуется вмешательство человека, а не «умной» автоматики. На то они и сложные.

Не понял, к чему ты это. Для протокола: мое «человеческое вмешательство» сводилось к выбору одного из предложенных aptitude вариантов (apt-get просто фейлил).

да и пусть себе изобретают libsolv, но другой. может быть от этого даже будет польза.

vold, а возникают такие проблемы, наверно, когда подключаем левые репы типа бэкпортов или ставим пакеты из unstable, да? :)

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

К тому же разные пакеты пакуются разными мантейнерами и они не всегда могут синхронно обновлять пакеты по разным причинам. Отсюда невозможность оперативно обновлять софт.

Если мантейнер следует http://www.altlinux.org/Shared_Libs_Policy , то оно так как-то и получается.

А они придерживаются?

чаще да. но всех, понятно, не заставишь.

Суть ухватил, но увы в деталях работы rpm в альт, к сожалению, не разбираюсь. От любого дистрибутива мне хотелось иметь в пакетном менеджере одинаково удобную возможность установки пакетов как из бинарных репозиториев, так и из исходников. Пока более менее только портежи и палудис этому удовлетворяют. А почему выбор пал на разработку, к примеру, а не доработку палудис? Не проще к нему свой клиент сделать?

Нет. Читай внимательнее.

Прочитал. «Для сборки документации используется python-module-sphinx-devel». То есть, всё в порядке только в случае, если кому-то нужен этот "-devel". А если он не нужен ?

Тогда не будет сверхсоложных зависимостей между пакетами и той самой NP-полной задачи по их разруливанию.

Воот, ты первый человек который меня понял :). А то некоторые кидаются решать проблемы которые сами и создают :).

В этом и поинт, альт не продемонстрировал понимание того куда надо двигаться. Была какая-то работа на малограммотную публику в духе «вот есть такая либа, libsolv называется, вот она ацтой, а мы хотели её прикрутить».

В интервью сказано, что они не собираются использовать при определении зависимостей рекурсивных методов:

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

а прикрутят их в качестве эксперимента.

А почему выбор пал на разработку, к примеру, а не доработку палудис?

Тут не знаю, я, всё же, больше пользователь, собирающий несколько нужных мне пакетов. В проблемы управления пакетами не вникаю сильно глубже, чем требуется для решения моих задач. Кроме того, лично я слово «палудис» только сегодня прочитал тут.

Да бред они пишут. Вот уже за одно это статью можно не читать:

гарантированный минимум, подходящий под требования промышленного применения

Я так и не распарсил. Это применение в промышленности? Это применение на боевых серверах? Что есть гарантированный минимум? Что есть максимум? Где между минимумом и максимумов находятся современные решения?

А почему выбор пал на разработку, к примеру, а не доработку палудис?

Ага: «менеджер программных пакетов, подхода „построение из исходных кодов“ (source-based)». Это несколько не то. Всё же, тут rpm останется в основе.

Почему бы не сделать так в линуксе? Или это технически сложно, нужно всю о/с перекурочить?

Патамушта. Вот у меня на корпоративной икспишечки не ставится ихний же проджект. Что ни выбирай из компонентов и как не прыгай после нажатия на кнопку инсталл говорит: фигвам, ошибка установки. Просто без всяких кодов и прочих зависимостей. Мне тут подсказали что оно чувствительно к дотнету и его версиям. Только говорят тебе проще вынести винду и с нуля всё запилить. Вот такой он оригинальный, лицензионный, элитный софт без зависимостей.

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

Прочитал.

Что и требовалось доказать. Полиси никто не читает.

Он уже может и бинарники. Но, что мешает сделать свой "cave"? И почему нельзя как в портежах предусматривать установку из исходников с возможностью как разной оптимизации, так и различного функционала пакета? Зачем все-все-все тащить за собой?

Воот, ты первый человек который меня понял :). А то некоторые кидаются решать проблемы которые сами и создают :).

Я думаю, это не проблема одного Альта (сложные зависимости, проблемы сборки и безопасного обновления пакетной базы без разломов и потери работоспособности части программ). Только разные дистрибутивы по-разному решают эту проблему. Некоторые статической сборкой (по сути упрощают зависимости), другие автоматической пересборкой репов (потом собирают ручками то, что не собирается и тестируют), третьи стабилизируются на старой пакетной базе (когда всё собирается со всем благодаря наличию оттестированной старой пакетной базы, только подбери нужные версии). Альты шли вторым путём.

Да бред они пишут. Вот уже за одно это статью можно не читать:

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

Что и требовалось доказать. Полиси никто не читает.

Я ещё не упаковывал ни одного rpm-macros-* (и планов нет даже), так что руководствовался приведёнными по ссыле цитатами и написанным в баге. :-)

А почему выбор пал на разработку, к примеру, а не доработку палудис? Не проще к нему свой клиент сделать?

Свой код легче делать под свои задачи, чем просить далёкого дядю вносить твои патчи. Апстрим может посчитать, что для него твои задачи не актуальны. Тогда всё равно надо будет делать форк и кодить самому.

И почему нельзя как в портежах предусматривать установку из исходников с
возможностью как разной оптимизации, так и различного функционала пакета?

Потому, что это просто другая парадигма: не из исходников.

В этом полностью согласен. Иной раз с нуля реализовать и поддерживать намного легче. Мой косяк.

Мне поэтому и не подходит, например, альт. Желательны оба варианта в одном флаконе.

руководствовался приведёнными по ссыле цитатами и написанным в баге.

Я так и понял.

Совершенно не сложно. Но не нужно.

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

Мне поэтому и не подходит, например, альт. Желательны оба варианта в одном флаконе.

Проблема в том, на что ориентирован дистрибутив. Представь 100500 рабочих станций, где всё поставлено из исходников с непойми какими ключами. Даже при идентичном железе возможны совсем неодинаковые грабли (ага, а у ALT ещё техподдержка есть, вообще-то... вот им здорово будет...). С другой стороны, что мешает пересобрать нужный src.rpm со своим набором зависимостей и параметров сборки, а, потом, захолдить в apt.conf ?

а у ALT ещё техподдержка есть

Made my day! Пишите ещё.

Я так и понял.

Цитаты - они даются для чего-то. Если цитаты не в тему, что ж тогда ?

а у ALT ещё техподдержка есть

Made my day! Пишите ещё.

Ну, про неё же пишут. :-)

Не нужно скорее программистам

Вот им, как раз, меньше нужно, так как оно работы больше добавить может. :-)

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

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

Полиси - они пишутся для чего-то. Если полиси не в тему, что ж тогда ?

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

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

Ну, про неё же пишут. :-)

Да, пишут. Вот сама «поддержка» и пишет - http://sibskull.livejournal.com/48689.html?thread=425521#t425521

факкен лолд!

Держи плюсик в карму.

С другой стороны, что мешает пересобрать нужный src.rpm со своим набором зависимостей и параметров сборки, а, потом, захолдить в apt.conf

А насколько сложно это делается технически?

Компьютерры

Она еще живая? Внезапно.

каждый пакет имеет ссылки на требуемые пакеты - идем во все прописанные и берем последнюю подходящую версию.

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

Почему появляется NP-сложность?

Потому и появляется что крупные программы в которых правильные зависимости не вкомпилены имеют тенденцию рассыпаться а ментейнеры не железные чтобы всё успевать починить. Видеоредакторы в линуксе падают не просто так а системно.

Полиси - они пишутся для чего-то. Если полиси не в тему, что ж тогда ?

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

Чего я не пойму, так почему не изменить просто саму ОС так, что-бы одновременно разное ПО подтягивало нужные им версии библиотек? Создать пакеты с ПО, которые ставятся в /opt к примеру. И монтирует что нужно перед запуском ПО так, что-бы у программы под рукой было нужное именно ей окружение из нужных версий библиотек и других ресурсов. Тогда проблема с зависимостями будет решатся просто - какая версия пакета, от которого ПО зависит нужна - ту и получит данный пакет.

Не один я имел траблы с редакторами видео? Чего только не пробовал, один bleder показал достойную стабильность. Но работать в нём с нелинейным монтажём немного не удобно, а наложение эффектов перехода совсем не интуитивно сделанно. Да и эффектов мало, и титры делать не в чём... Офтоп в деле радактирования рулит, да и маки тоже линь заруливают. Нет просто пока для него редактора видео приличного, а подделки на пистоне не могут заменить профессиональное ПО.

Да, пишут. Вот сама «поддержка» и пишет

Про «все CVE», конечно, я слышал. :-) Но всё и так, и не так. Надо ли пояснять, что, кроме Server 4.0, был ещё и branch 4.0, и там таки было несколько лучше ? А обновление сервера до бранча было вполне себе нормальным решением, по крайней мере, как практика показала. Собственно, Server 4.0 я использовал всегда только как инсталятор, а, потом, перенастраивал apt на бранч.

А насколько сложно это делается технически?

1. качается нужный src.rpm
2. ставится в каталог пользователя
3. ставится пакет rpm-build
4. в спеке делаются нужные изменения
5. rpm -bb <spec-файл>
6. если ругается на -devel пакеты, доустановить.

Не сложно для человека, который что-то знает про сборку пакетов. Это не с нуля спек написать.

Ну если же даёшь цитаты на косяк, они ж, цитаты, должны его отражать ?

Они отражают, а ты просто не умеешь читать.