Re: [devel-distro] mki-copy-efiboot fixes

[Alexey Gladkov <legion@altlinux.ru>]

On Mon, Aug 17, 2020 at 08:47:00PM +0300, Michael Shigorin wrote:
> On Mon, Aug 17, 2020 at 06:56:19PM +0200, Alexey Gladkov wrote:
> > Я зарефакторил mki-copy-efiboot. Теперь его будет проще
> > поддерживать. Плюс я нашёл несколько небольших ошибок в нём.
> > Заинтересованных прошу посмотреть.
> 
> Заинтересовался, посмотрел, по коммитам -- в конце письма.
> 
> > http://git.altlinux.org/people/legion/packages/mkimage.git?a=shortlog;h=refs/heads/dev
> 
> "А что, так можно было?!" (ц) ;-)
> 
> Н-да, что ж я не додумался до такого, когда его писал
> и отлаживал... да и у тебя помощи не попросил.
> 
> Но это одна часть проблемы (развесистая логика, которая была
> выписана по сути под конкретное семейство ISO -- регулярки,
> стартеркиты и дистрибутивы альта), вторая остаётся: эта
> функциональность именно в развесистом виде была втащена в mkimage
> потому, что не хотелось спихивать с mkimage-profiles-desktop
> принудительно при наличии возможности сделать и там поддержку
> малыми затратами.
> 
> 
> То есть _тогда_ у меня при реализации функциональности выбор был
> -- делать её _и_ в m-p, _и_ в m-p-d, или же помучиться и сделать
> единообразно в mkimage; решение для меня было очевидным.
> 
> А _сейчас_ m-p-d проводили на пенсию естественным путём,
> поскольку там никто не делал работы по поддержке других
> архитектур (и технически она была куда сложней, даже с m-p
> оказалось немало сюрпризов по мере взросления ARM).
> 
> И если бы архитектуры вынудили выпускать седьмой альт уже сразу
> на m-p (когда на нём были только стартеркиты), то я бы делал
> менюшки сразу там, а в mkimage ограничился краткой и ясной
> базовой функциональностью, если не дали уже готовую конфигурацию
> загрузчика.

Напрашиваются шаблоны для элементов меню, которые можно было бы создавать
и держать вне mkimage. Тогда часть хардкода из mki-copy-efiboot ушла бы.

> Собственно, по такой логике mki-copy-efiboot и развивался
> -- сперва что-то базовое, затем "навороты".
> 
> Например, там и посейчас остался прибитый гвоздиком список
> языков для передачи lang=... в cmdline инсталятору/livecd.
> Задумка была сделать фичу l10n в mkimage-profiles, которая
> обеспечит включение нужных пакетов локализации (сейчас они
> гвоздиком же прибиты в различных дистрибутивных списках),
> возможно, станет влиять на %_install_langs и т.д.
> 
> Да, можно изобрести хоть include в mkimage и подтыкать
> генерируемые кусочки из профиля -- я бы такое делать
> "потому что могу" не стал, а только если будет нужно
> другим авторам профилей (в первую очередь Большакову).
> 
> 
> Тут, собственно, Антон скорее моими давними соображениями
> и руководствуется, когда делает/включает такие генераторы
> в mkimage-profiles, а не предлагает в mkimage: это больше
> головной боли, чем реюзабельной функциональности, и лучше
> бы её тащить в другие места или обобщать тогда, когда это
> окажется осмысленным.
> 
> Или вот поддержка memtest86.efi -- там примерно такая же
> петрушка: Большакову не нужно, я заморачивался ради rescue
> и дистрибутивов.
> 
> 
> В общем, тут по сути твоё решение о том, чем ты видишь mkimage --

mkimage это alt-specific инструмент для сборки образов в разных форматах.
В нём собраны сценарии не завязанные на конкретный альтовый дистрибутив.

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

> я считаю, что ужасам вроде даже моего mki-copy-efiboot (а с тех
> пор он, смотрю, ещё разросся) там не место, потому что такой код
> является _плохим_ примером, в отличие от твоего краткого.

Ну теперь-то уж он останется надолго.

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

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

> Есть и прозаический момент по отладке: m-p правится в $HOME,
> mkimage -- или в /usr/share, или как boyarsh@ в своё время
> ухитрялся -- тоже в $HOME, но нетривиально (уже не помню, как);

`make MKLOCAL=1` ?

> --------------------------------------------------------------
> 
> По коммитам:
> 
> * Reformat -- руками или чем-нить вроде indent(1)?

Руками.

> * Refactor generation of refind submenu -- дифф глазами
>   нормально не разобрал, но сами функции после него
>   выглядят заметно чище, конечно
> 
> * Move code for ia32efi_flag=present in one place --
>   хорошо бы nickel@ проверил такую сборку, в Обнинске
>   вроде была IA32 EFI-машинка

Для этого я это в отдельный бранч и положил :)

> * Avoid using "type -t" in the posix code --
>   намотал на ус (но я на POSIX и не претендовал)
> 
> Другие фиксы тоже почитал, на один commit message
> предложу такой фикс:
> 
> -is already exists
> +already exists
> 
> -If the
> +If

Когда буду перекладывать исправлю. Спасибо!

Из кода mki-copy-efiboot-chrooted я не понял:

* Я не понял, что кладёшь в forensic_args и почему ты уверен, что
  syslinux/isolinux.cfg всегда есть.

* Почему для rescue нельзя делать submenuentry c lang= ?

* В чём логика [ "$n_stages" -ne 1 ] при выборе icon ?

* Зачем нужно делать copy_mt86 и потом purge_mt86. Ты же уже всё упаковал.
  Зачем удалять ?

* Я не понял манипуляций с "$efi/$shell". Ты сначала его копируешь в одно
  место, потом в другое, потом mcopy ...

Я ещё хочу подумать о том чтобы распилить mki-copy-efiboot на несколько
составных частей (shim, elilo, grub-efi, refind), которые будут
параметризованы, а mki-copy-efiboot будет их вызывать.

-- 
Rgrds, legion