LINUX.ORG.RU

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

 ,


0

1

Существующие менеджеры пакетов для Linux часто критикуют за высокую для неопытных пользователей сложность, трудности с разрешением зависимостей между пакетами и тому подобные вещи. О новых подходах к управлению установленными программами задумываются разработчики многих дистрибутивов, и российские компании не исключение. Инженер-программист «Альт Линукс», кандидат технических наук Михаил Пожидаев рассказал «Компьютерре» о Deepsolver — перспективной разработке, которая может заменить в дистрибутивах ALT Linux использующийся сейчас «Advanced Packaging Tool» (APT).

>>> Подробности

★★

Проверено: maxcom ()

Ответ на: комментарий от anonymous

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

geekless ★★ ()
Ответ на: комментарий от tailgunner

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

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

geekless ★★ ()
Ответ на: комментарий от anonymous

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

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

AS ★★★★★ ()
Ответ на: комментарий от raorn

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

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

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

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

AS ★★★★★ ()
Ответ на: комментарий от geekless

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от raorn

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

Popil_Bablosov ()
Ответ на: комментарий от true_admin

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

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

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

vold ★★★★★ ()
Ответ на: комментарий от AS

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

glibych ★★ ()
Ответ на: комментарий от raorn

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

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

AS ★★★★★ ()
Ответ на: комментарий от vold

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

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

vold ★★★★★ ()
Ответ на: комментарий от glibych

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

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

AS ★★★★★ ()
Ответ на: комментарий от vold

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от glibych

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

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

AS ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от AS

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

glibych ★★ ()
Ответ на: комментарий от AS

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

glibych ★★ ()
Ответ на: комментарий от true_admin

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

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

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

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

vold ★★★★★ ()
Ответ на: комментарий от raorn

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

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

AS ★★★★★ ()
Ответ на: комментарий от glibych

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

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

vold ★★★★★ ()
Ответ на: комментарий от glibych

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

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

AS ★★★★★ ()
Ответ на: комментарий от vold

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

glibych ★★ ()
Ответ на: комментарий от AS

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

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

anonymous ()
Ответ на: комментарий от glibych

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

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

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

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

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

AS ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от AS

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

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

glibych ★★ ()

Компьютерры

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

damnemall ()
Ответ на: комментарий от VoDA

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

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

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от raorn

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

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

AS ★★★★★ ()

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

lucentcode ★★★★★ ()
Ответ на: комментарий от Napilnik

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

lucentcode ★★★★★ ()
Ответ на: комментарий от raorn

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

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

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от glibych

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

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

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

AS ★★★★★ ()
Ответ на: комментарий от AS

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

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

raorn ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.