From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=vyPy8i9FgRTbHkfciWw0m/jQSycu42ixgcevUcLD/xw=; b=S00tlY0iFu5ICd6bA/EmmhmsmASa8Qlmx2cGW+vbncN8ho+k/yevDpnqyqu45CP2Q/ G5wlqERa+E6Vf8j7ge4bNUuVC0eWEldxDWgyvXqhV/Sr7rW1rxaaSYH29NihqfQmDujb rSLvm6ejB0a4jwL5V1qwGwKm3XpPxn1CdUtAAZmtVZ7uCn07CJDMMLIbWRN8+MJsziIt 2D+rt3Jq3nWsZ0BUW33jXQs1hlpvBbqVQpT+b7WXYWyodWbNjgC2iAZdEn5N95zVvOjD MO18d2hJzYpdRweGq8RTPqeqcQsv1sUp1OQAlD8oOj95tXhZoF89epUlNFVIZMXeeB3M TeUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vyPy8i9FgRTbHkfciWw0m/jQSycu42ixgcevUcLD/xw=; b=gc5XO75ImaIhadd8c72YETduGLAQhQv2Z4F1o2So8coPJ7h/KpthKALkOcuetHYOTA Jp8E8jaNmCgw2i4+IXdTUidmq2KWvkspMYJYlTmO/DruTTmKT2dd/5eXhQ2UjjfGP5YD ISxChXTkTKBeKLebq6S+0khc4WEfO9pYYE3p8J4jsxGV0/9Q5Rlo0KKRm4QAvXZkN+0j G4gcYwfkIBqI7A/8mmtjxcgg60rfMvZEKXZdWlaxE7LEZ2tqGbYDUtK7V2fqHlYEyr7a Yrt1Ja4vRpJ3X6BVBgxBitfVwCs2UK0b9im2Px42+o/U1fEpCnt/CkzNJDL/Dr6iBl75 85Cg== X-Gm-Message-State: AOAM531VwZkyIfqgTb93NtFo6cyOOz4QAhp6zCTBB9XT6Gowki6diGD+ f/EoM4pIh3nYU7YZU63wJ4KYf/d+W7M= X-Google-Smtp-Source: ABdhPJzY1rtZpqexIuNLuiPsLuosauynqwQW/68C12J76uxHliqYUgUqUXHby4Pl7Q7vXQKgDG4I3A== X-Received: by 2002:a2e:5c86:: with SMTP id q128mr800946ljb.150.1632364811917; Wed, 22 Sep 2021 19:40:11 -0700 (PDT) To: make-initrd@lists.altlinux.org References: <20210922100901.e5dsw554g6elb3lx@example.org> <52f4526d-7fa7-e0ed-6d2d-12e06f20408c@gmail.com> <20210922114132.yaobsgcz7vrkjgbq@example.org> <8d262440-d8fc-c174-3293-1964e3440617@gmail.com> <20210922130839.b4iwv2arqyggczb3@example.org> <20210922144619.3h4va7j4u6m36mka@example.org> <20210922190348.rrn3cjywjwwcrhbl@example.org> <20210923004510.vwdythqavekqoow3@example.org> From: Leonid Krivoshein Message-ID: Date: Thu, 23 Sep 2021 05:40:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20210923004510.vwdythqavekqoow3@example.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [make-initrd] =?utf-8?b?dWRoY3BjIHNjcmlwdCDQsiDRhNC40YfQtSBuZXR3?= =?utf-8?q?ork?= X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 02:40:17 -0000 Archived-At: List-Archive: 23.09.2021 3:45, Alexey Gladkov пишет: > On Thu, Sep 23, 2021 at 01:06:33AM +0300, Leonid Krivoshein wrote: >>> Ты где-то отдельно пишешь код >> Код отправляю пока в Сизиф и в локальную гитовницу: >> >> git.altlinux.org/people/klark/packages/make-initrd-bootchain.git > Это отдельный репозиторий, делать ревью коммитов непонятно как. > git.alt/people это почти худшее место для обсуждения хода. Даже тарболл и > патчи в рассылке лучше. > > Ты несколько раз говорил про него, но я просто не знаю, что с ним делать. > > Я уже понял, что этот репозиторий живёт своей жизнью и имеет свою историю > изменений. Эта история безусловно важна и выкидывать её будет ошибкой. Но > проблема в том, что я не представляю как это мерджить поскольку это даже > как subtree сделать. Это WiP, история и патчи там черновые, даже с опечатками. Нет смысла держаться за такое. Всё делалось исходя из намеченного плана. > Моё предыдущее предложение сделать патчсет уже не актуально в данной > ситуации. Я предполагал, что у тебя будет некая минимальная реализация, а > остальное мы доработали бы в рабочем порядке. В этом случае все изменения > бы ли бы рабочими и проходили обсуждение. Увы, это всё теперь невозможно. Скажу честно, с момента написания черновика документации, все коммиты в m-i-b кода не сильно прибавили, изменения коснулись, в основном, исправления найденных ошибок и недочётов. Т.е. размер на момент публикации в Сизифе примерно таким и был. Для обсуждения предлагалась самая первая минимальная реализация без диалогов. Ты её сильно раскритиковал и тогда я сделал вторую, уже с диалогами, в виде монолитной фичи. А это третья реализация, модульная, она такой практически и была изначально. Я не предлагаю перетаскивать doc -- это совершено не готовая часть для разработчиков и тестировщиков, туда как раз ушла часть кода от исходно опубликованной версии, ещё из дерева удалена вторая реализация. Так что я как раз готовил проект к апстриму. > Но ты выбрал иную стратегию. Ты разрабатываешь вещь в себе в отдельном > репозитории. Это просто некое отдельное решение на основе make-initrd. Ну, подожди, мы же обсуждали эту стратегию: публикация в Сизифе для более широкомасштабного тестирования на регулярках и по готовности апстрим. Она не в себе, а уже делалась с учётом множества твоих замечаний. И сейчас не разрабатывается, а скорее дорабатывается и исправляется. > Этот репозитории повторяет стратегию make-initrd-propagator, который > как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в > себе. Новый, правда, интегрирован с основным кодом лучше. Я так понимаю, это всё из-за интеграции с network. Но посуди сам: pipeline и network, плюс ещё несколько новых фич, это и есть тот набор, что ты сделал на замену пропагатора, я лишь приделываю к этому диалоги и совместимость с нынешним stage2. Если что-то не так приделываю, можно же это предметно обсуждать. Да, я сначала думал делать полный или частичный форк фичи network, потому что были большие сомнения, что удастся с ней интегрироваться. Но это последнее, что нужно было altboot, чтобы быть больше похожим на propagator (по возможностям) и удалось обойтись без форка, в отличии от pipeline. Ты можешь сказать, чем плоха такая интеграция? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918 -- работает просто идеально. >>> вместо того чтобы обсуждать и порциями добавлять. >> Если бы работы по обсуждённому ранее плану были завершены, мне бы только и >> оставалось, что добавлять порциями. Но к сожалению работы ещё много. Ты сам >> настаивал, чтобы продукт был тщательно проверен до того, как он поедет в >> апстрим. Находятся замечания, предложения, приходится их устранять и >> учитывать. А из-за этого у меня откладывается работа по автоматизации >> тестового стенда. Конечно лучше, чтобы в апстрим поехал безупречно >> работающий продукт. Ты и сам уже можешь посмотреть код в Сизифе, пощупать >> очередные регулярки с разными опциями и методами загрузки. >> >> Лично мне кажется, что ни один пакет у нас так пристально не проверялся, >> попадая в обычные продукты. Но altboot -- важное звено в процессе загрузки и >> моя задача учесть совместимость с уже сделанным в Альте за многие годы. > Я начинаю думать, что уже лучше оставить всё как есть сейчас. Пусть > make-initrd-bootchain остаётся отдельным репозиторием и пакетом. > > Когда в make-initrd будут появляться новые интерфейсы или фичи, то они > будут начинать использоваться в make-initrd-bootchain. В том числе, когда > какой-то функционал будет переползать в апстрим. > > Иначе я просто не представляю как всё уже написанное поддерживать. Код bootchain-core + bootchain-getimage + bootchain-waitdev сопоставим с нынешним pipeline. Предлагаю поступить так: эти три я сделаю одним патчсетом. Главное, чтобы твои автотесты не забраковали, т.к. совместимость с pipeline там соблюдена. Остальное можно сделать как хочешь -- каждую фичу одним патчем, всё в пределах одного выпуска. Я соберу тестовое задание, мы его протестируем, а как поддерживать -- уже вопрос наживной. При локализации проблем в области bootchian/altboot просто добавлять меня в cc: багов. Благо bc_debug позволяет собрать нужную диагностику. > [...] >> Как раз я старался учесть возможность перехода в будущем на более правильные >> концепции. Но сейчас и тебе надо принять, как данность, что пусть >> "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был >> внутри make-initrd > Вот тут ты ошибаешься. Мне не нужно и тебе не советую принимать как > данность, что нужно повторять поведение, которое написано в 2004. Это > поведение чуть-чуть устарело. > > Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем > его переизобретать. Выше озвучивались не просто общие слова -- у нас куча граблей и нет способа быстро перейти на make-initrd + pipeline с ними. Вот простейший пример, мы готовимся избавиться от isolinux для legacy/x86, но сколько это будет тянуться -- неизвестно. Он сам (его брэндинг) добавляет опции пропагатора в загрузку и на это приходится ориентироваться, так как если не работает, сразу баг. >> и работал как 1/80 часть его рантайма, а не наоборот, >> чтобы настоящий propagator полностью выкидывал и заменял собой все 100% >> рантайма make-initrd. > Признаюсь тебе: мне нет дела до propagator. Это древний кусок гов^W кода. > Раньше он замечательно работал без make-initrd. Он делает всё сам и своими > методами. > > Считаю ли я, что _функционал_ propagator может быть реализован на > make-initrd ? Да. Именно это и делает altboot. > Считаю ли я, что поведение propagator нужно воспроизводить ? Нет. В каком смысле? Я не копировал его повеление в точности. Но методы -- нужны, совместимость со stage2 -- нужна. Многое сделано лучше и модульно, это нельзя назвать 100% копией поведения. И всё делалось в пределах исходной концепции pipeline, код декомпозирован. > Я считаю, что должна быть сохранена совместимость до определённой степени. > Я не считаю, что нужна полная копия поведения. Для последнего у вас есть > сам propagator. Его уже начали капитально переделывать под новые реалии. Но без меня. >> Можно и нужно обсуждать, как лучше сделать это, не >> ломая совместимости, и учитывая потребности перехода на что-то более >> правильное в перспективе. > Ты сам себе противоречишь. Я должен принять, как данность функционал > пропагатора и не ломая совместимости с кодом 17 летней (на самом деле > большей) давности переходить на что-то более правильное. Коду инсталлятора уже 17 лет? Пропагатор был его первой частью. У ОС Альт есть два варианта при выкидывании пропагатора -- жить без инсталлятора или найти новый. К обеим вариантам пока не готовы. Перелопачивать старый -- тоже пока нет ресурсов. Так что замена в make-initrd должна быть адекватной. Но кроме инсталлятора есть ещё загрузчики, сетевая установка (alterator-netinst), да ещё куча всего, плюс документация. Это всё нужно переделывать. Сейчас это нереально. > И при этом ты пишешь, что не потянешь сопровождение. Другими словами жить > с и переписывать эту "данность" с учётом совместимости буду я ? Отличная > перспектива. Вот тут я не понял, что ты предлагаешь. Изначально весь код делался как часть make-initrd, это же твой проект. Не, ну давай будем поддерживать всем миром. )) Мне кажется, что моя помощь в написании кода, документации, методики тестирования и инструментов для автоматизации тестирования с лихвой покроет даже моё неучастие в дальнейшей судьбе. Но я могу помогать с поддержкой, по возможности, хотя слабо представляю, как это возможно, когда это войдёт в состав make-initrd. > А давайте сначала вы осознаете, что вам не нужен клон propagator и будете > апстримить уже стазу более правильное ? Мы осознавали, что нам без этого не обойтись с самого начала, это обсуждалось ещё после первой же пробной версии. Иначе нужно осознать, что выкинуть нам придётся очень много, что невозможно без адекватной замены. > Потому что сейчас всё что, сказал выглядит не очень здорово. Выглядит так, > что пропагатор переписанный разом на форк pipeline мне пытаются скинуть на > поддержку. Да, есть немного и такого дела. А как бы ты хотел? Я тебя прекрасно понимаю. Вчера собрались регулярки и не грузится RPi4, сразу ко мне вопрос. В результате altboot оказался не причём, но так мне хотя бы спокойнее будет, а тебе какая разница, 80 тыс. строк кода поддерживать или 86 тыс., ты же к такому уже привык!? :-) >>> И я до сих пор не видел ни одного патча. Поэтому для >>> меня каждая твоя проблема является большим сюрпризом. >> Кажется, несколько попыток я уже делал, в частности, отдельно предлагал >> bootchain-interactive. > Патчей или PR так и не было. Я собирал тестовые задания с патчами, приводил тут на них ссылки. Нет у меня на гитхабе аккаунта или я не очень понимаю в этой терминологии. [...] > Так это неправильно. Пользователь может такое хотеть. Да и дело не только > в dhcp -> static. Нужно уметь расконфигурировать интерфейс. Да, согласен, но до этого мы ещё дожили на данном этапе развития. >> if [ ! -s /bin/network-sh-functions ]; then > В 2.22.0-13-g78001064a я специально реализовал проверку фич о которой мы > говорили. Да, но я на 2.23 только сегодня первый раз собрал, у меня до этого более старая версия была. Понятно, что надо будет менять в коде всё, о чём говорили, если уже появилось в make-initrd. >> А полная совместимость с пропагатором требует другого синтаксиса > А зачем эта совместимость ? Ты пишешь про это как про аксиому. Потому что есть целая куча пакетов и документации в продуктах к ним, которые его используют. Например, для работы со слоями NFS, для сетевой установки. Я уже говорил выше, что речь о совместимости именно с этими многолетними наработками, которые разом не выкинуть, не заменить. > Я не хочу отвлекаться на кулстори, но когда мы с inger@ писали инсталлер, > то как-то пережили отсутствие совместимости с mandrake. А тут внезапно > появилось желание иметь совместимость с его частью. Я тоже не люблю совместимость, хочется всё с нуля написать. Но порою это дольше. >>> [...] >>> Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны >>> на системном уровне, чтобы весь код был готов к изменению параметров, но >>> почему-то меня не услышали. >> Тебе видней, как это реализовать на системном уровне, разве кто-то будет >> возражать! Я не так хорошо пока знаю архитектуру make-initrd, но предлагал >> перетащить на верхний уровень bootchain-interactive > Я не понял как ты предлагал это перетакивать. Скопировать код в другой > репозиторий ? п.7 здесь (самый конец): https://lists.altlinux.org/pipermail/make-initrd/2021-August/000521.html и первый ответ тут: https://lists.altlinux.org/pipermail/make-initrd/2021-August/000525.html я был уверен, что уже удалил то задание, но нет. :-) так это и был патч для make-initrd с фичей interactive. > [...] >>>>>> Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у >>>>>> нас снимется много вопросов о том, как интегрировать bootchain/interactive с >>>>>> уже имеющимися фичами make-initrd. Будет хороший пример, как это можно >>>>>> сделать. >> P.S.: Если хочешь, давай остановимся на версии 0.1.5-alt3 и начнём её >> апстримить. Вот прямо сегодня! :-) > Я уже высказался про это выше. Всё это время я следовал договорённостям. Так что ты меня сильно удивил. Не веришь -- склонируй к себе версию 0.1.5-alt3, удали bootchain-doc, т.к. его не предлагаю пока апстримить, посчитай объём чем-нибудь типа du/wc, а затем обнули до initial commit и сравни с полученным. Ничего тут не увеличилось, я в этом уверен. 200 строк -- не та разница, из-за которой это становится неподъёмной ношей. Мы занимаемся просто причёсыванием и доводкой до абсолютно рабочего состояния. -- Best regards, Leonid Krivoshein.