Интервью с Алексеем Брагиным, координатором проекта ReactOS

> это бред. любому дураку ясно почему из скрипта это с хотя бы 80% вероятность не выдрать...

man bash, искать --rpm-requires

Ничего личного, но дурак здесь - ты.

>это бред. любому дураку ясно почему из скрипта это с хотя бы 80% вероятность не выдрать...

Это не бред, это факт:)

>Мальчег, пивной ларёк != большая контора:)

Кому как не тебе об этом знать.

>которая рещает 80% задач, это лучше, чем отсуствие автоматизации?

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

вот если бы в папку с ./configure клали некий DEPS с зависимостями в стандартизованной форме... было бы несомненно круто.

>они не являются необходимостью при сборке пакета

я имел ввиду, что из них можно зависимости без всяких "анализов" брать.

> вот если бы в папку с ./configure клали некий DEPS с зависимостями в стандартизованной форме... было бы несомненно круто.

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

>вот если бы в папку с ./configure клали некий DEPS с зависимостями в станвот если бы в папку с ./configure клали некий DEPS с зависимостями в стандартизованной форме... было бы несомненно круто.дартизованной форме... было бы несомненно круто.

>я имел ввиду, что из них можно зависимости без всяких "анализов" брать.

Ты просто путаешся в понятиях:) Зависимости сборки и рантайм-зависимости - это не одно и то же:)

>>которая рещает 80% задач, это лучше, чем отсуствие автоматизации?

>меня не устраивает автоматизация при которой я не уверен что она работает с 100% вероятностью

У тебя пик юношеского максимализма, похоже. Ни одна автоматизация не работает со 100% вероятностью. Ни одна вообще - ошибки есть во всех программах.

> после такого авто-определения, вдруг обнаруживается что комп засран недоопределившимися зависимостями

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

у меня в дебиановском баше нет этой опции.

ты мне теоретически обьясни как это может работать, даже если bash специально патчен.

если там (грубо говоря)нетривиальное вычисление имени вызываемой программы, или имя программы узнаётся от другой вызванной программы ? 


--rpm-requires что, ИИ обладает ? 

>но дурак здесь - ты.

cам дурак если веришь что --rpm-requires работает всегда.

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

>Ни одна автоматизация не работает со 100% вероятностью.

бред. если автор пакета написал все зависимости в интерпретируемой софтом форме, то это считай и есть 100% вероятность.(потому что его ошибки в данном контексте разумеется не учитываются)

>Похоже, ты не собрал ни одного пакета в жизни,

argumentum ad hominem ? я был о тебе лучшего мнения.

>тогда что?

Как что? Известное дело: "я самый умный, а вы все дураки!". Он же в каждом втором посте это говорит:)

> cам дурак если веришь что --rpm-requires работает всегда.

Цитата из тебя: "любому дураку ясно почему из скрипта это с хотя бы 80% вероятность не выдрать...". Ты определись, во что не веришь - в то, что всегда, или в то, что даже в в 80%? Кстати, цитата из man bash: "some dependencies may be missed".

Ладно, хочешь оставить за собой последнее слово - оставь.

> argumentum ad hominem

Ни один человек, собиравший пакеты, не напишет об автоопределении зависимостей _таких_ страшилок. Других - да, но не таких.

> я был о тебе лучшего мнения.

Меня часто считают лучше, чем я есть %)

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

>"some dependencies may be missed".

чтд.

>или в то, что даже в в 80%

ну хрен его знает ,этот софт, может процентов не 80 а 90. но мне проще посмотреть в README или INSTALL пред удалением вручную или перед созданием пакета, чем полагаться на вероятности...

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

На основании чего ты пытаешся доказать? Я могу доказать обратное на основании многолетнего опыта сборки сотен разных пакетов. Срабатывание этого "ИИ" (как ты его называешь) - ок. 98%. Т.о. ок. 98% времени он мне экономит. "Подметать срач" вобще никогда не приходилось.

>но мне проще

или make unistall который редко присутствует или правильно работает.

>98%. Т.о. ок. 98%

ну это от балды. мы же не имеем возможности провести статистическое исследование ....

к примеру всё что связанно с perl'ом, ocaml'ом,haskell , питон'ом, сommon лиспом, могут иметь способы подгрузки зависимостий которые не связанны ни с бинарями ни с bashем...

у меня (на глаз) >процентов 40% совта, который явно требует ручного подхода к зависимостям...

>ну это от балды. мы же не имеем возможности провести статистическое исследование ....

"От балды" - это у тебя. А я сказал на чём основывается моя статистика:)

>к примеру всё что связанно с perl'ом, ocaml'ом,haskell , питон'ом, сommon лиспом, могут иметь способы подгрузки зависимостий которые не связанны ни с бинарями ни с bashем...

>у меня (на глаз) >процентов 40% совта, который явно требует ручного подхода к зависимостям...

У тебя >40% софта на хаскеле-питоне-лиспе-перле-окамле?:)

>как ты его называешь

нет. ИИ я называю то, что является ИИ. это автоопределение - эвристика.

>ИИ я называю то, что является ИИ. это автоопределение - эвристика.

Ты продолжаешь путать понятия. автоопределение != эвристика.

>А я сказал на чём основывается моя статистика:

у меня свой набор совта, своя статистика.

>У тебя >40% софта на хаскеле-питоне-лиспе-перле-окамле?:)

нет, но большая часть из них, по некоторым причинам, у меня установлены вручную (половина через checkinstall) вместе с сторонними либами.

>>А я сказал на чём основывается моя статистика:

>у меня свой набор совта, своя статистика.

Секретная?:)

>нет, но большая часть из них, по некоторым причинам, у меня установлены вручную (половина через checkinstall) вместе с сторонними либами.

Я думаю, тут уже все поняли, по каким "причинам":)

>линупса

К логопеду, быдло!

да, автоопределение != эвристика.

но данный способ автоопределения - очень даже "эвристика"(в кавычках)

>да, автоопределение != эвристика.

>но данный способ автоопределения - очень даже "эвристика"(в кавычках)

Если для тебя парсинг == "эвристика", тогда да:)

Ты всегда выдумываешь новые термины, вместо существующих? папки вместо каталогов, эвристика (с ИИ) вместо парсинга. Ты, случайно, велосипеды самолётами не называешь?:)

>линакс

К логопеду, быдло!

>Секретная?:)

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

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

>Я думаю, тут уже все поняли, по каким "причинам":)

ну давай. я не понял. пошути.

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

>нет, ну а что, я по поводу срача на лоре должен весь свой набор совта всрывать

Мне здесь трудно тебя понять, потому как я "срача" у себя никогда не наблюдал.

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

как минимум, перл, shell, пайтон - мимо кассы. Они отлично "автоопределяются". На счёт ocaml и haskel - точно не скажу. Приведи, плиз, внешние рантайм-зависимости ocaml/haskel.

>>Я думаю, тут уже все поняли, по каким "причинам":)

>ну давай. я не понял. пошути.

Ну какие тут шутки? Всё очень серьёзно: по причинам сильно завышенного самомнения, неспособности В ПРИЦИПЕ признавать свою неправоту даже в деталях, недостаточного образования и неспособности (или нежелания) "образоываться".

zort - каким образом нечёткое определение зависимостей связано с тем, что после удаления останется какой-то мифический срач в системе?

Если ты ставишь что-то, что тянет за собой N пакетов (неважно - правильно или нет, лишние или что-то забыто), то ты хочешь сказать что в том же debian при удалении этого пакета из его N зависимостей у тебя что-то останется на винте?

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

все остальные тоже могут вызывать программы, поэтому по той же причине - не мимо кассы. Жаба с её навороченными плагинными фреймворками - совсем прямо в кассу.

eщё есть "не исполняемые зависимости", - картинки там всякие

>Приведи, плиз, внешние рантайм-зависимости ocaml/haskel.

почему обязательно рантайм, можно и не рантайм. вот устанавливаю я какой нибудь пакет для haskellя, который в свою очередь зависит от другого(в дебиане пакеты эти начинаются с libhugs-), а т.к. автоопределитель вряд ли умеет понимать зависимости haskell'я и другой экзотики из исходников(я сильно удивлюсь если это так), то он не добавит в зависимости нужного пакета.

из рантайм - весь эклипс и netbeans - рантайм. и всё что на их платфоме.

>по причинам сильно завышенного самомнения, неспособности В ПРИЦИПЕ признавать свою неправоту даже в деталях, недостаточного образования и неспособности (или нежелания) "образоываться".

между прочим получилась смешная шутка! ;)

>зависимостей у тебя что-то останется на винте?

ну может произойти другая ситуация.

пакет A и B зависят от G, но связь B с G не быля установлена. в результате при удалении A, улалися и G, а B стал нерабочим.

кстати, в RPM есть аналог дебианского "A" атрибута пакета? Если его нет, то мой "срач при удалении" релевантен.

ЗЫ В дебиане ведь вроде нет автоматического распознавания зависимостей как в rpm, поэтому к нему это точно отношения не имеет.

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

Судя по грамматике предложений и знаний возможностей существующих технологий уже понятен уровень образования. А область деятельности уже не важна ;)

>ёпт, какой нах парсинг, даун ? задача этого автоопределения - не парсинг, а "точное" выяснение того набора и состояния файлов, от которого зависит работа данного совта в данных условиях, с данными дефолтными конфигами...

А вновь придуманную сказку на ночь и вновь сочинённую "песенку" для будильника утром не надо?:)

>задача этого автоопределения - не парсинг, а "точное" выяснение того набора и состояния файлов, от которого зависит работа данного совта в данных условиях, с данными дефолтными конфигами

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

Если что, это я не тебе говорю, а тем новичкам, которые случайно сюда забрели. Они же не знают, сколько здесь IQ-неотягощённых...

>почему обязательно рантайм, можно и не рантайм. вот устанавливаю я какой нибудь пакет для haskellя, который в свою очередь зависит от другого(в дебиане пакеты эти начинаются с libhugs-), а т.к. автоопределитель вряд ли умеет понимать зависимости haskell'я и другой экзотики из исходников(я сильно удивлюсь если это так), то он не добавит в зависимости нужного пакета.

Раз устанавливаешь - заничт уже рантайм-зависимости.

Почему "из-исходников"?

>из рантайм - весь эклипс и netbeans - рантайм. и всё что на их платфоме.

Java-зависимости тоже нормально вычисляются.

>eщё есть "не исполняемые зависимости", - картинки там всякие

Программа зависит от картинки... Смерть от смеха точно кому-то гарантирована.

>файла который вручную создал разработчик "совта",

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

кроме самого файла потребуется ещё и интеграция с ./configure скриптами, на случай кастом настроек.

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

Ага, а куча говна в реестре невсчет.

>Я сам стандартизовать такой файл предложил. сейчас таких файлов нет.

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

А скрипт ./configure берёт информацию о необходимых зависимостях из астрала.

>Почему "из-исходников"?

потому что для hugs'а надо в исходниках

>Раз устанавливаешь - заничт уже рантайм-зависимости.

рантайм зависимости - это такие зависимости которые грузятся исходя из логики запущенной программы.

>Java-зависимости тоже нормально вычисляются

ну давай рассказывай, как космические корабли боро^W^W^W find-requires анализирует нетбинсовские или эклипсные (или какие другие)xml конфиги...

>Программа зависит от картинки... Смерть от смеха точно кому-то гарантирована.

А то! И эта картинка, конечно же из другого "покета", и эта картинка называется "C:\Local Settings\Вася Пупкин\Мои Документы\Я со своим бумером.jpg":)

ну и как из ./configure (который бывает не только autotools) выдрать этот набор ?

набор для чего? если для сборки, то с помощью strace(1) это делается (по крайней мере - в rpm'овском buildreq).

> А ведь вся эта структура в unix не просто так сделана. Может лучше прочитать и понять почему все так, а не иначе сделано. >Потому что делалось это в 70ых годах с поправкой на реалии того времени. Потом нерды-очкарики привыкли и не стали это менять даже когда компы уже позволяли сделать что-то более продуманное. Ну и наконец появились всякие пионеры которые глядя на очкариков которые с этими компами по 30 лет возились решили что это очень круто. А практической пользы от этого полный ноль.

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

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

как strace будет анализировать подобную логику: ?

проверяем наличие пакета A, его нет, пытаемся проверить наличие B как альтернаивы A, отлично - найден, ставим галочку которая позвалит завершиться ./configure скрипту успешно. Сама программа писанна на С, вызывает B через пайп во время работы(типа фронтэнд к B). Анализ системных вызовов ./configure не позволит отличить A от B.

>ну и как из ./configure (который бывает не только autotools) выдрать этот набор ?

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

>задаёшь такие тупые вопросы. Куда катится мир...

никаким сравнением по образцу это не выдрать.