[devel-distro] mkimage-profiles 1.4.18-alt1

[devel-distro] mkimage-profiles 1.4.18-alt1

[Антон Мидюков]

Здравствуйте

Доступна новая версия mkimage-profiles 1.4.18-alt1.

Изменения следующие:

- Если переменная BRANCH не пуста, а переменная BRANDING напротив пуста, то BRANDING назначаем alt-starterkit.
  Если переменная BRANCH пуста и переменная BRANDING пуста, то BRANDING назначаем, как раньше, alt-sisyphus

- Отменил коммит добавления eepm в Rescue, чтобы не будоражить конспирологические теории о продавливании
  чего-то там и кем-то там...

- Исправлены условия с переменной BRANCH. Теперь можно задавать пустое значение BRANCH, чтобы перекрыть
  уже заданное значение в ~/.mkimage/profiles.mk

- Убрана ставшая ненужной цель mixin/starterkit и переменная STARTERKIT, которой присваивалась эта цель,
  если задана переменная BRANCH

- Добавил субменю для grub Network installation с четырьмя методами: ftp, http, nfs, cifs. Но его полезность
  пока сомнительна. Также добавил новую цель use/stage2/net-install, которая добавляет это субменю и поддержку
  этих методов в stage1

- Добавлена новая фича initrd-bootchain на замену initrd-propagator. Вместо propagator используется набор фич
  make-initrd-bootchain-*, разработанных Леонидом Кривошеиным (klark@). Если переменная BRANCH пуста (собираем 
  для Сизифа), то iso образ будет собран с make-initrd-bootchain, если задан BRANCH, то с propagator.
  Исключением является e2k, для которого всё также будет осуществляться сборка propagator.

- Появилась возможность собирать образ только со stage1. Нужно для сборки образа с сетевой загрузкой

- Из всех регулярок/стартеркитов был убран udev-rule-generator-net. В rootfs без NetworkManager был добавлен
  livecd-net-eth вместо преднастройки интерфейса eth0

- В фиче ntp исправлена цель use/ntp, теперь она действительно добавляет openntpd, если переменная
  THE_NTPD не задана

- Исправлена сборка образов на p9, использующих use/vmguest/kvm/x11. Необходимо при сборке задать переменную BRANCH=p9

- В syslinux и grub в пункты загрузки инсталятора (install2) и rescue добавлен lowmem. При локальной загрузке
  с propagator для метода cdrom lowmem включался всегда и так. И лишь с disk имел значение, но disk включался
  лишь в syslinux для локальных накопителей. Для bootchain же lowmem имеет значение всегда. К тому же метод cdrom
  в инсталяторе с отключенным lowmem приводит к ошибке в скрипте preinstall.d/99-cdrom.sh

- В проверку доступности пакетов при создании профиля сборки добавлены переменные *_PACKAGES и *_PACKAGES_REGEXP.
  Их содержимое попадает в одноимённые списки в pkg, после проверки эти временные списки удаляются

- В grub, syslinux в пунктах меню rescue аргумент cmdline ядра 'splash=0' был заменён на более современный 'nosplash'.
  Использование splash=0 в propagator с plymouth к переключению на tty5, что совершенно нежелательно для rescue 

- Удалены устаревшие фичи: aarch64-dbm, armh-cubox, armh-dovefb, nexus7, armh-tegra, armh

- В armh-mcom02 в initrd добавлены drm модули, чтобы framebuffer инициализировался уже в initrd, и можно было обойтись
  без подключения последовательной консоли. Где-то год назад кто-то из тестировщиков спрашивал, чтоб так можно было.
  Лучше поздно, чем никогда

- Исправил перекрытие FEATURES из /etc/initrd.mk в features.in/build-vm/image-scripts.d/17-kernel переменной VM_INITRDFEATURES.
  Аналогично сделал и для VM_INITRDMODULES. Так что теперь при сборке vm/, заданные непосредственно в /etc/initrd.mk
  FEATURES и MODULES_TRY_ADD перекрываться не будут

- Конфиг syslinux/isolinux.cfg генерируется теперь и в случае, если собирается образ с grub-pc. Этот конфиг нужен для alterator-netinst.

- Для build-vm и stage2 теперь включается GLOBAL_HSH_PROC=1 (доступ к /proc из hasher), так как make-initrd с версии 2.23.0 более активно
  использует возможности bash и поэтому не может обойтись без доступа к /proc

- В vm/cloud-system добавлен модуль ядра sr_mod в initrd (коммит от obirvalger@)

Страница проекта: https://www.altlinux.org/Mkimage/Profiles/m-p

История анонсов: https://www.altlinux.org/Mkimage/Profiles/m-p/news

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Michael Shigorin]

On Mon, Sep 20, 2021 at 11:45:46PM +0700, Антон Мидюков wrote:
> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
>   конспирологические теории о продавливании чего-то там и кем-то
>   там...

А можно подробнее/ссылочку?  Как вариант, отправляй конспирологов
ко мне -- выясним, кто это их с диверсиями направляет и подрывает
вурлд доминейшун нашей спасалочки :]

(eepm в base+regular добавлял ещё в 2013 году, если что)

> - Убрана ставшая ненужной цель mixin/starterkit и переменная
>   STARTERKIT, которой присваивалась эта цель, если задана
>   переменная BRANCH

Не смотрел на реализацию, но внешне переменная, которая относится
к одной из частных целей, выглядит совсем-совсем костылём...

> - Добавлена новая фича initrd-bootchain на замену
>   initrd-propagator. Вместо propagator используется набор фич
>   make-initrd-bootchain-*, разработанных Леонидом Кривошеиным
>   (klark@). Если переменная BRANCH пуста (собираем для Сизифа),
>   то iso образ будет собран с make-initrd-bootchain, если задан
>   BRANCH, то с propagator.  Исключением является e2k, для
>   которого всё также будет осуществляться сборка propagator.

Да, bootchain ещё совсем не проверял -- пока не до того.

> - Появилась возможность собирать образ только со stage1.
>   Нужно для сборки образа с сетевой загрузкой

Такая возможность когда-то давно уже была -- см. коммит
ad687508559d47941b3b6c54c9d119f99e05bdcd и цель
distro/server-ovz-netinst... (удалено тоже давно коммитом
1345c6e041d5d2a411b60fce67bddf24fca6db39 по причине кончины
той машинки, где эти эксперименты выкладывались -- т.к.
адрес был по необходимости зашит и в загрузочный образ)

> - Из всех регулярок/стартеркитов был убран
>   udev-rule-generator-net

Совсем доломали ядро вместе с udev?

>   В rootfs без NetworkManager был добавлен livecd-net-eth
>   вместо преднастройки интерфейса eth0

...что лишает возможности сделать образ с чем-либо кроме dhcp 
при помощи фичи net-eth; надеюсь, данное улучшение исправимо.

> - В syslinux и grub в пункты загрузки инсталятора (install2) и
>   rescue добавлен lowmem. При локальной загрузке с propagator для
>   метода cdrom lowmem включался всегда и так. И лишь с disk имел
>   значение, но disk включался лишь в syslinux для локальных
>   накопителей. Для bootchain же lowmem имеет значение всегда.

Возможно, пора это в bootchain назвать как-то иначе (обрабатывая
по старинке и lowmem так же).

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

Размеры оперативной памяти и минимальный порог загружаемости
std-def последние лет десять росли быстрее, чем размер install2,
как мне кажется.

В общем, сейчас оно по смыслу noramdisk скорее или что-то такое.

Но можно и не трогать, конечно.

>   К тому же метод cdrom в инсталяторе с отключенным lowmem
>   приводит к ошибке в скрипте preinstall.d/99-cdrom.sh

...который как раз и занимался реализацией многодисковой
установки, когда в рамках школьного проекта (2008 год же!)
опять понадобилась (что-то поставляли на CD1/CD2).

> - В armh-mcom02 в initrd добавлены drm модули, чтобы
>   framebuffer инициализировался уже в initrd, и можно было
>   обойтись без подключения последовательной консоли. Где-то год
>   назад кто-то из тестировщиков спрашивал, чтоб так можно было.
>   Лучше поздно, чем никогда

Это, кстати, не только на mcom02 бывает полезно.
Может пригодиться обобщить механизм.

Спасибо за труды!

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Антон Мидюков]

21.09.2021 01:08, Michael Shigorin пишет:
> On Mon, Sep 20, 2021 at 11:45:46PM +0700, Антон Мидюков wrote:
>> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
>>   конспирологические теории о продавливании чего-то там и кем-то
>>   там...
> 
> А можно подробнее/ссылочку?  Как вариант, отправляй конспирологов
> ко мне -- выясним, кто это их с диверсиями направляет и подрывает
> вурлд доминейшун нашей спасалочки :]
> 
> (eepm в base+regular добавлял ещё в 2013 году, если что)
> 

https://lists.altlinux.org/pipermail/devel-distro/2021-August/002522.html

>> - Убрана ставшая ненужной цель mixin/starterkit и переменная
>>   STARTERKIT, которой присваивалась эта цель, если задана
>>   переменная BRANCH
> 
> Не смотрел на реализацию, но внешне переменная, которая относится
> к одной из частных целей, выглядит совсем-совсем костылём...
> 

Это был костыль, от которого избавился.

>> - Добавлена новая фича initrd-bootchain на замену
>>   initrd-propagator. Вместо propagator используется набор фич
>>   make-initrd-bootchain-*, разработанных Леонидом Кривошеиным
>>   (klark@). Если переменная BRANCH пуста (собираем для Сизифа),
>>   то iso образ будет собран с make-initrd-bootchain, если задан
>>   BRANCH, то с propagator.  Исключением является e2k, для
>>   которого всё также будет осуществляться сборка propagator.
> 
> Да, bootchain ещё совсем не проверял -- пока не до того.
> 

Мне кажется надо генерацию конфига e2k поменять. В generate.sh переделать.
Иначе придётся несколько переменных дополнительно в глобальные экспортировать.

>> - Появилась возможность собирать образ только со stage1.
>>   Нужно для сборки образа с сетевой загрузкой
> 
> Такая возможность когда-то давно уже была -- см. коммит
> ad687508559d47941b3b6c54c9d119f99e05bdcd и цель
> distro/server-ovz-netinst... (удалено тоже давно коммитом
> 1345c6e041d5d2a411b60fce67bddf24fca6db39 по причине кончины
> той машинки, где эти эксперименты выкладывались -- т.к.
> адрес был по необходимости зашит и в загрузочный образ)
> 

А я для всех разрешил:
59a0470b2868276622ad8d0c4e195eee15b7d887

>> - Из всех регулярок/стартеркитов был убран
>>   udev-rule-generator-net
> 
> Совсем доломали ядро вместе с udev?
> 

Нет. Хотелось предсказуемости. Пусть непривычные имена, зато более стабильные.

>>   В rootfs без NetworkManager был добавлен livecd-net-eth
>>   вместо преднастройки интерфейса eth0
> 
> ...что лишает возможности сделать образ с чем-либо кроме dhcp 
> при помощи фичи net-eth; надеюсь, данное улучшение исправимо.
> 

Это касается только регулярок.

>> - В syslinux и grub в пункты загрузки инсталятора (install2) и
>>   rescue добавлен lowmem. При локальной загрузке с propagator для
>>   метода cdrom lowmem включался всегда и так. И лишь с disk имел
>>   значение, но disk включался лишь в syslinux для локальных
>>   накопителей. Для bootchain же lowmem имеет значение всегда.
> 
> Возможно, пора это в bootchain назвать как-то иначе (обрабатывая
> по старинке и lowmem так же).
> 
> В mdk stage1 этот режим подразумевался действительно для машин,
> у которых не хватало памяти для зачитывания в неё инсталятора,
> чтобы дальше было возможно в первую очередь диски менять (ну и
> работать немного быстрей).
> 
> Размеры оперативной памяти и минимальный порог загружаемости
> std-def последние лет десять росли быстрее, чем размер install2,
> как мне кажется.
> 
> В общем, сейчас оно по смыслу noramdisk скорее или что-то такое.
> 
> Но можно и не трогать, конечно.

Да пусть так пока будет. Когда и если похороним propagator, тогда
можно будет и совместимость с ним нарушать.

> 
>>   К тому же метод cdrom в инсталяторе с отключенным lowmem
>>   приводит к ошибке в скрипте preinstall.d/99-cdrom.sh
> 
> ...который как раз и занимался реализацией многодисковой
> установки, когда в рамках школьного проекта (2008 год же!)
> опять понадобилась (что-то поставляли на CD1/CD2).
> >> - В armh-mcom02 в initrd добавлены drm модули, чтобы
>>   framebuffer инициализировался уже в initrd, и можно было
>>   обойтись без подключения последовательной консоли. Где-то год
>>   назад кто-то из тестировщиков спрашивал, чтоб так можно было.
>>   Лучше поздно, чем никогда
> 
> Это, кстати, не только на mcom02 бывает полезно.
> Может пригодиться обобщить механизм.

Да там нет никакого механизма. Для mcom02 ничего лишнего не собрано,
поэтому добавил каталог с drm-модулями ядра в initrd.
Для каждой железки могут потребоваться свои модули.

> 
> Спасибо за труды!
> 


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Leonid Krivoshein]

Привет!


20.09.2021 21:08, Michael Shigorin пишет:
>> - Добавлена новая фича initrd-bootchain на замену
>>    initrd-propagator. Вместо propagator используется набор фич
>>    make-initrd-bootchain-*, разработанных Леонидом Кривошеиным
>>    (klark@). Если переменная BRANCH пуста (собираем для Сизифа),
>>    то iso образ будет собран с make-initrd-bootchain, если задан
>>    BRANCH, то с propagator.  Исключением является e2k, для
>>    которого всё также будет осуществляться сборка propagator.
> Да, bootchain ещё совсем не проверял -- пока не до того.

Его пока рано смотреть. До версии 0.1.7 вряд ли стоит. Если образы e2k 
собираются с make-initrd, то локальная загрузка (cdrom, disk) должна 
работать нормально. А сетевую загрузку допиливаем на пару с Антоном 
Мидюковым. Сколько роутеров на пути, столько сюрпризов. =)) В целом, я 
слышал, что на aarch64 тоже грузится.


>> - Появилась возможность собирать образ только со stage1.
>>    Нужно для сборки образа с сетевой загрузкой
> Такая возможность когда-то давно уже была -- см. коммит
> ad687508559d47941b3b6c54c9d119f99e05bdcd и цель
> distro/server-ovz-netinst... (удалено тоже давно коммитом
> 1345c6e041d5d2a411b60fce67bddf24fca6db39 по причине кончины
> той машинки, где эти эксперименты выкладывались -- т.к.
> адрес был по необходимости зашит и в загрузочный образ)

Рабочее название "netstart" по подобию "сетевой стартеркит", чтобы не 
путать с alterator-netinst, у которого тоже сетевая загрузка, но с 
другим смыслом. А как у тебя решалась проблема разницы в модулях ядра в 
stage1 и stage2? Через kexec или оверлеем нужные модули ядра 
дотаскивались до чрута?


>> - В syslinux и grub в пункты загрузки инсталятора (install2) и
>>    rescue добавлен lowmem. При локальной загрузке с propagator для
>>    метода cdrom lowmem включался всегда и так. И лишь с disk имел
>>    значение, но disk включался лишь в syslinux для локальных
>>    накопителей. Для bootchain же lowmem имеет значение всегда.
> Возможно, пора это в bootchain назвать как-то иначе (обрабатывая
> по старинке и lowmem так же).

Вот бы сразу дать осмысленное название, тогда сделаем алиас. Если, 
конечно, названий в пространстве /proc/cdmline не жалко. :-)


> В mdk stage1 этот режим подразумевался действительно для машин,
> у которых не хватало памяти для зачитывания в неё инсталятора,
> чтобы дальше было возможно в первую очередь диски менять (ну и
> работать немного быстрей).
>
> Размеры оперативной памяти и минимальный порог загружаемости
> std-def последние лет десять росли быстрее, чем размер install2,
> как мне кажется.
>
> В общем, сейчас оно по смыслу noramdisk скорее или что-то такое.

Для этих целей сейчас в bootchain нужно не указывать ramdisk_size=<N> -- 
тогда вместо /dev/ramN будет использоваться tmpfs. Это же является 
fallback'ом для realtime ядер, т.к. они собраны без поддержки ramdisk. 
Совсем отказаться от этого можно не во всех случаях, например, для 
методов ftp/http образ надо куда-то сначала загрузить.


> Но можно и не трогать, конечно.

lowmem вполне годный переключатель, я не против его переименовать по уму.


>>    К тому же метод cdrom в инсталяторе с отключенным lowmem
>>    приводит к ошибке в скрипте preinstall.d/99-cdrom.sh
> ...который как раз и занимался реализацией многодисковой
> установки, когда в рамках школьного проекта (2008 год же!)
> опять понадобилась (что-то поставляли на CD1/CD2).

Да пора бы уже исправить этот косяк -- там скрипт не проверяет backing 
device и рассчитывает только на /dev/loopN.


> Спасибо за труды!

Ох, да! Присоединяюсь!


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Vitaly Lipatov]

Антон Мидюков писал 20.9.21 19:45:
> Здравствуйте
> 
> Доступна новая версия mkimage-profiles 1.4.18-alt1.
> 
> Изменения следующие:
> 
> - Если переменная BRANCH не пуста, а переменная BRANDING напротив
> пуста, то BRANDING назначаем alt-starterkit.
>   Если переменная BRANCH пуста и переменная BRANDING пуста, то
> BRANDING назначаем, как раньше, alt-sisyphus
> 
> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
> конспирологические теории о продавливании
>   чего-то там и кем-то там...
А вы от лица компании Базальт СПО удалили eepm из rescue или это ваша 
персональная ответственность и ваш персональный проект rescue?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Ivan A. Melnikov]

On Mon, Sep 20, 2021 at 09:08:57PM +0300, Michael Shigorin wrote:
> On Mon, Sep 20, 2021 at 11:45:46PM +0700, Антон Мидюков wrote:
> >   В rootfs без NetworkManager был добавлен livecd-net-eth
> >   вместо преднастройки интерфейса eth0
> 
> ...что лишает возможности сделать образ с чем-либо кроме dhcp 
> при помощи фичи net-eth; надеюсь, данное улучшение исправимо.

DHCP_TIMEOUT теперь тоже нельзя задать?

-- 
  wbr,
    iv m.

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Антон Мидюков]

21.09.2021 12:29, Ivan A. Melnikov пишет:
> On Mon, Sep 20, 2021 at 09:08:57PM +0300, Michael Shigorin wrote:
>> On Mon, Sep 20, 2021 at 11:45:46PM +0700, Антон Мидюков wrote:
>>>   В rootfs без NetworkManager был добавлен livecd-net-eth
>>>   вместо преднастройки интерфейса eth0
>>
>> ...что лишает возможности сделать образ с чем-либо кроме dhcp 
>> при помощи фичи net-eth; надеюсь, данное улучшение исправимо.
> 
> DHCP_TIMEOUT теперь тоже нельзя задать?
> 

1. Это изменение коснулось только регулярок
2. В фичах mipsel-* вызывается use/net-eth, так что им должно быть без разницы
3. Неплохо было бы DHCP_TIMEOUT задавать и для новых соединений, а не только
для существующих. Надо подумать, как это сделать.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

[devel-distro] rescue швейцарский нож (was: mkimage-profiles 1.4.18-alt1)

[Sergey V Turchin]

20.09.2021 21:08, Michael Shigorin пишет:
> On Mon, Sep 20, 2021 at 11:45:46PM +0700, Антон Мидюков wrote:
>> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
>>    конспирологические теории о продавливании чего-то там и кем-то
>>    там...
> 
> А можно подробнее/ссылочку?
https://lists.altlinux.org/pipermail/devel-distro/2021-August/002523.html

[...]

-- 
Regards, Sergey

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Антон Мидюков]

21.09.2021 14:00, Sergey V Turchin пишет:
> 20.09.2021 19:45, Антон Мидюков пишет:
>> Здравствуйте
>>
>> Доступна новая версия mkimage-profiles 1.4.18-alt1.
> Спасибо!
> 
>> Изменения следующие:
>>
>> - Если переменная BRANCH не пуста, а переменная BRANDING напротив пуста, то BRANDING назначаем alt-starterkit.
>>    Если переменная BRANCH пуста и переменная BRANDING пуста, то BRANDING назначаем, как раньше, alt-sisyphus
> Это просто затычка для переменной BRANDING, если пустая, правильно?
> 

Да. Раньше всегда затыкалось alt-sisyphus, теперь же, если задана переменная BRANCH, то будет BRANDING alt-starterkit.

Переменную же BRANCH надо теперь задавать для сборки на бранчах. Так как иначе сборка обломится из-за недоступности
make-initrd-bootchain. Это касается сборки iso.

И чтобы BRANCH была не обузой, а полезным средством сборки под разные бранчи, советую настроить ~/.mkimage/profiles.mk
подобным образом:

ifneq (,$(BRANCH))
APTCONF = ~/apt/apt.conf.$(BRANCH).$(ARCH)
else
APTCONF = ~/apt/apt.conf.sisyphus.$(ARCH)
endif

Чтобы использовался при её задании соответствующий конфиг.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] rescue швейцарский нож (was: mkimage-profiles 1.4.18-alt1)

[Michael Shigorin]

On Tue, Sep 21, 2021 at 10:01:58AM +0300, Sergey V Turchin wrote:
> >> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
> >>    конспирологические теории о продавливании чего-то там и кем-то
> >>    там...
> > А можно подробнее/ссылочку?
> https://lists.altlinux.org/pipermail/devel-distro/2021-August/002523.html

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

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

В общем, да, именно таким я его задумывал и делал.
Это _не_ узконаправленный scalpel, fdisk или mtx.
См. тж. http://altlinux.org/rescue :-)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Michael Shigorin]

On Tue, Sep 21, 2021 at 02:27:09PM +0700, Антон Мидюков wrote:
> И чтобы BRANCH была не обузой, а полезным средством сборки
> под разные бранчи, советую настроить ~/.mkimage/profiles.mk
> подобным образом:
> 
> ifneq (,$(BRANCH))
> APTCONF = ~/apt/apt.conf.$(BRANCH).$(ARCH)
> else
> APTCONF = ~/apt/apt.conf.sisyphus.$(ARCH)
> endif
> 
> Чтобы использовался при её задании соответствующий конфиг.

Собственно, почти дословно это и предлагает doc/branch.txt :-)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Антон Мидюков]

21.09.2021 16:36, Michael Shigorin пишет:
> On Tue, Sep 21, 2021 at 02:27:09PM +0700, Антон Мидюков wrote:
>> И чтобы BRANCH была не обузой, а полезным средством сборки
>> под разные бранчи, советую настроить ~/.mkimage/profiles.mk
>> подобным образом:
>>
>> ifneq (,$(BRANCH))
>> APTCONF = ~/apt/apt.conf.$(BRANCH).$(ARCH)
>> else
>> APTCONF = ~/apt/apt.conf.sisyphus.$(ARCH)
>> endif
>>
>> Чтобы использовался при её задании соответствующий конфиг.
> 
> Собственно, почти дословно это и предлагает doc/branch.txt :-)
> 

Я его чуток актуализировать забыл.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Michael Shigorin]

On Tue, Sep 21, 2021 at 01:36:25AM +0700, Антон Мидюков wrote:
> >> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
> >>   конспирологические теории о продавливании чего-то там и кем-то
> >>   там...
> > А можно подробнее/ссылочку?  Как вариант, отправляй конспирологов
> > ко мне -- выясним, кто это их с диверсиями направляет и подрывает
> > вурлд доминейшун нашей спасалочки :]
> > (eepm в base+regular добавлял ещё в 2013 году, если что)
> https://lists.altlinux.org/pipermail/devel-distro/2021-August/002522.html

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

А rescue, который тоже умеет режим с сессиями (и может быть
развёрнут в качестве основы системы, как написал чуть раньше)
-- вполне удачное место для попадания в т.ч. и eepm.

hasher и базовое сборочное окружение, разумеется, настолько ценны,
что мы не поленились сделать особый образ builder, где они
работают из коробки (и туда я, пользуясь админресурсом своих двух
корявок, зафигачил не только mkimage с mkimage-profiles, но ещё
и примеры использования в ~altlinux/.bash_history; кстати,
можно аналогичное -- lsblk, fdisk -l, ... -- добавить в rescue).

> >> - Убрана ставшая ненужной цель mixin/starterkit и переменная
> >>   STARTERKIT, которой присваивалась эта цель, если задана
> >>   переменная BRANCH
> > Не смотрел на реализацию, но внешне переменная, которая относится
> > к одной из частных целей, выглядит совсем-совсем костылём...
> Это был костыль, от которого избавился.

Да-да, это заметил; прокомментировал на будущее, ты с такими
костылями (сам же их способен охарактеризовать) стучись и
спрашивай до того, как их делать да коммитить: вдруг в две
головы что-нить дельное сразу придумаем.

> >> - Добавлена новая фича initrd-bootchain на замену
> >>   initrd-propagator. Вместо propagator используется набор фич
> >>   make-initrd-bootchain-*, разработанных Леонидом Кривошеиным
> >>   (klark@). Если переменная BRANCH пуста (собираем для Сизифа),
> >>   то iso образ будет собран с make-initrd-bootchain, если задан
> >>   BRANCH, то с propagator.  Исключением является e2k, для
> >>   которого всё также будет осуществляться сборка propagator.
> > Да, bootchain ещё совсем не проверял -- пока не до того.
> Мне кажется надо генерацию конфига e2k поменять. В generate.sh
> переделать.  Иначе придётся несколько переменных дополнительно
> в глобальные экспортировать.

Ну сделай левокоммит да пришли вместе с ц/у, если понадобятся.
Хотя мне было бы спокойней уже после выпуска десятой версии,
наверное.

> >> - Появилась возможность собирать образ только со stage1.
> >>   Нужно для сборки образа с сетевой загрузкой
> > см. коммит ad687508559d47941b3b6c54c9d119f99e05bdcd [...]
> А я для всех разрешил:
> 59a0470b2868276622ad8d0c4e195eee15b7d887

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

> >> - Из всех регулярок/стартеркитов был убран
> >>   udev-rule-generator-net
> > Совсем доломали ядро вместе с udev?
> Нет. Хотелось предсказуемости. Пусть непривычные имена,
> зато более стабильные.

Как тебе сказать.  На системе с одним eth при нормальных ядре
и udev получаем именно что стабильное eth0.

То, что _в ядре_ начали вытворять ради уродств, которые по
неграмотности своей натворили в systemd -- я цензурно
охарактеризовать не могу (в итоге в cmdline _ядра_ сейчас
бывают параметры, указывающие версию _systemd_ -- это безумие
какое-то уже полное).  Впрочем, здесь это флейм и офтопик.

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

> Когда и если похороним propagator, тогда можно будет
> и совместимость с ним нарушать.

И то лучше оставить, где это несложно. :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Michael Shigorin]

On Mon, Sep 20, 2021 at 10:01:14PM +0300, Leonid Krivoshein wrote:
> >> - Появилась возможность собирать образ только со stage1.
> >>    Нужно для сборки образа с сетевой загрузкой
> > см. коммит ad687508559d47941b3b6c54c9d119f99e05bdcd
> А как у тебя решалась проблема разницы в модулях ядра в stage1
> и stage2? Через kexec или оверлеем нужные модули ядра
> дотаскивались до чрута?

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

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] mkimage-profiles 1.4.18-alt1

[Leonid Krivoshein]

21.09.2021 12:50, Michael Shigorin пишет:
> On Mon, Sep 20, 2021 at 10:01:14PM +0300, Leonid Krivoshein wrote:
>>>> - Появилась возможность собирать образ только со stage1.
>>>>     Нужно для сборки образа с сетевой загрузкой
>>> см. коммит ad687508559d47941b3b6c54c9d119f99e05bdcd
>> А как у тебя решалась проблема разницы в модулях ядра в stage1
>> и stage2? Через kexec или оверлеем нужные модули ядра
>> дотаскивались до чрута?
> Какой там kexec, зачем?  У меня обеспечивалось именно одно ядро,
> в том-то и дело.  Т.е. для работы с бранчем такой инсталятор надо
> автоматически пересобирать, перепроверять и перевыкладывать после
> каждого обновления применяемого ядра.  Ну или париться вручную.

Понятно. Одинаковое ядро с модулями в stage1 и stage2 не так интересно. 
:-) Понятно, что так оно будет работать в любом случае. Оверлей с 
модулями и фирмварью можно же передавать в stage2 при монтировании 
слоёв. А через kexec можно решить ещё и проблему с передаваемыми через 
/proc/cmdline параметрами, как это делает coreboot. То есть, речь о 
сетевой загрузке с целых ISO-образов, в stage1 выбирается ISO'шник и 
загрузочный пункт меню.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] rescue швейцарский нож (was: mkimage-profiles 1.4.18-alt1)

[Sergey V Turchin]

21.09.2021 12:28, Michael Shigorin пишет:
> On Tue, Sep 21, 2021 at 10:01:58AM +0300, Sergey V Turchin wrote:
>>>> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
>>>>     конспирологические теории о продавливании чего-то там и кем-то
>>>>     там...
>>> А можно подробнее/ссылочку?
>> https://lists.altlinux.org/pipermail/devel-distro/2021-August/002523.html
> 
> Подтверждаю с мелкой поправочкой: alt-rescue -- это российский
> армейский нож, некоторые его даже как основу для кластерного
> бездискового образа применяли (применяют?).
>
> Этот образ заодно пригоден
Точно, образ! Вот и делайте образ. Отдельный. Зачем всем портить?
Я ж вам в Rescue Plasma c LibreOffice не пихаю. А то у меня есть.

[...]

> В общем, да, именно таким я его задумывал и делал.
> Это _не_ узконаправленный scalpel, fdisk или mtx.
> См. тж. http://altlinux.org/rescue :-)
Не путайте, пожалуйста образ Rescue с компонентой rescue.


-- 
Regards, Sergey

Re: [devel-distro] rescue швейцарский нож

[Vitaly Lipatov]

Sergey V Turchin писал 21.9.21 15:45:
> 21.09.2021 12:28, Michael Shigorin пишет:
>> On Tue, Sep 21, 2021 at 10:01:58AM +0300, Sergey V Turchin wrote:
>>>>> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
>>>>>     конспирологические теории о продавливании чего-то там и кем-то
>>>>>     там...
>>>> А можно подробнее/ссылочку?
>>> https://lists.altlinux.org/pipermail/devel-distro/2021-August/002523.html
>> 
>> Подтверждаю с мелкой поправочкой: alt-rescue -- это российский
>> армейский нож, некоторые его даже как основу для кластерного
>> бездискового образа применяли (применяют?).
>> 
>> Этот образ заодно пригоден
> Точно, образ! Вот и делайте образ. Отдельный. Зачем всем портить?
> Я ж вам в Rescue Plasma c LibreOffice не пихаю. А то у меня есть.
...
> Не путайте, пожалуйста образ Rescue с компонентой rescue.
Просветите для общего развития: как используется компонента rescue кроме 
как для создания образа rescue и почему сотня Кб bash-скрипта 
сравнивается с Plasma&LibreOffice?

Возможно, я не понял структуры, но можно всё же в инструменте для 
сисадмина окажется epm?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel-distro] rescue швейцарский нож

[Anton Farygin]

On 22.09.2021 20:41, Vitaly Lipatov wrote:
> Sergey V Turchin писал 21.9.21 15:45:
>> 21.09.2021 12:28, Michael Shigorin пишет:
>>> On Tue, Sep 21, 2021 at 10:01:58AM +0300, Sergey V Turchin wrote:
>>>>>> - Отменил коммит добавления eepm в Rescue, чтобы не будоражить
>>>>>>     конспирологические теории о продавливании чего-то там и кем-то
>>>>>>     там...
>>>>> А можно подробнее/ссылочку?
>>>> https://lists.altlinux.org/pipermail/devel-distro/2021-August/002523.html 
>>>>
>>>
>>> Подтверждаю с мелкой поправочкой: alt-rescue -- это российский
>>> армейский нож, некоторые его даже как основу для кластерного
>>> бездискового образа применяли (применяют?).
>>>
>>> Этот образ заодно пригоден
>> Точно, образ! Вот и делайте образ. Отдельный. Зачем всем портить?
>> Я ж вам в Rescue Plasma c LibreOffice не пихаю. А то у меня есть.
> ...
>> Не путайте, пожалуйста образ Rescue с компонентой rescue.
> Просветите для общего развития: как используется компонента rescue 
> кроме как для создания образа rescue и почему сотня Кб bash-скрипта 
> сравнивается с Plasma&LibreOffice?
>
> Возможно, я не понял структуры, но можно всё же в инструменте для 
> сисадмина окажется epm?
>
А зачем он нужен на rescue ? ему же надо работать внутри устновленной 
системы

Re: [devel-distro] rescue швейцарский нож

[Sergey V Turchin]

22.09.2021 20:41, Vitaly Lipatov пишет:

[...]
> Возможно, я не понял структуры, но можно всё же в инструменте для 
> сисадмина окажется epm?
Какой ещё "инструмент сисадмина"?! Это не "ALT Sysadmin Tools" и даже не 
"Regular Rescue". Если бы его добавили в отдельный rescue.iso так, чтобы 
используя компоненты rescue*+* в mkimage-profiles я мог не захватывать, 
например, eepm и recoll, то я не был бы против. Т.е. если поместите в 
rescue+misc+extra, я за.

Это небольшая, но тенденция, что есть инициаторы запихивания 
несоответствующих пакетов в компоненты. Нескольких уже вынесли в 
rescue+x11+extra, но приходилось тратить время на доказательство, а это 
лишняя трата общего времени.

-- 
Regards, Sergey

Re: [devel-distro] rescue швейцарский нож

[Антон Мидюков]

23.09.2021 14:24, Sergey V Turchin пишет:
> 22.09.2021 20:41, Vitaly Lipatov пишет:
> 
> [...]
>> Возможно, я не понял структуры, но можно всё же в инструменте для сисадмина окажется epm?
> Какой ещё "инструмент сисадмина"?! Это не "ALT Sysadmin Tools" и даже не "Regular Rescue". Если бы его добавили в отдельный rescue.iso так, чтобы используя компоненты rescue*+* в mkimage-profiles я мог не захватывать, например, eepm и recoll, то я не был бы против. Т.е. если поместите в rescue+misc+extra, я за.
> 
> Это небольшая, но тенденция, что есть инициаторы запихивания несоответствующих пакетов в компоненты. Нескольких уже вынесли в rescue+x11+extra, но приходилось тратить время на доказательство, а это лишняя трата общего времени.
> 

Давайте тогда из pkg.in/lists/tagged/base+rescue уберём ещё и:

# Package management
apt-repo
aptitude

Зачем это в компоненте rescue? Я же посмотрел все списки и нашёл подходящее по смыслу место
(рядом с ними eepm вполне смотрится хорошо).
Если считаете, что в базовой части rescue не должно быть пакетного менеджера, то давайте перенесём
это в другой список.
Да и apt стоит тогда убирать. Я не против ревизии списков. Они действительно раздуты и порой нелогичны.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] rescue швейцарский нож

[Sergey V Turchin]

23.09.2021 10:39, Антон Мидюков пишет:
> 23.09.2021 14:24, Sergey V Turchin пишет:
>> 22.09.2021 20:41, Vitaly Lipatov пишет:
>>
>> [...]
>>> Возможно, я не понял структуры, но можно всё же в инструменте для сисадмина окажется epm?
>> Какой ещё "инструмент сисадмина"?! Это не "ALT Sysadmin Tools" и даже не "Regular Rescue". Если бы его добавили в отдельный rescue.iso так, чтобы используя компоненты rescue*+* в mkimage-profiles я мог не захватывать, например, eepm и recoll, то я не был бы против. Т.е. если поместите в rescue+misc+extra, я за.
>>
>> Это небольшая, но тенденция, что есть инициаторы запихивания несоответствующих пакетов в компоненты. Нескольких уже вынесли в rescue+x11+extra, но приходилось тратить время на доказательство, а это лишняя трата общего времени.
>>
> 
> Давайте тогда из pkg.in/lists/tagged/base+rescue уберём ещё и:
> 
> # Package management
> apt-repo
> aptitude
Я не против убирания aptitude. apt-repo можно для удобства оставить.

> Зачем это в компоненте rescue?
apt-repo может понадобиться в процессе установки доп.софта, а eepm точно 
ничем не поможет.

> Я же посмотрел все списки и нашёл подходящее по смыслу место
> (рядом с ними eepm вполне смотрится хорошо).
> Если считаете, что в базовой части rescue не должно быть пакетного менеджера, то давайте перенесём
> это в другой список.
Пакетный менеджер нужен для установки недостающих пакетов.
А eepm там зачем?

> Да и apt стоит тогда убирать.
Зачем крайности? Так можно и до "серпом по ..." дойти. ;-)

> Я не против ревизии списков. Они действительно раздуты и порой нелогичны.


-- 
Regards, Sergey

Re: [devel-distro] rescue швейцарский нож

[Anton Farygin]

On 23.09.2021 11:08, Sergey V Turchin wrote:
> 23.09.2021 10:39, Антон Мидюков пишет:
>> 23.09.2021 14:24, Sergey V Turchin пишет:
>>> 22.09.2021 20:41, Vitaly Lipatov пишет:
>>>
>>> [...]
>>>> Возможно, я не понял структуры, но можно всё же в инструменте для 
>>>> сисадмина окажется epm?
>>> Какой ещё "инструмент сисадмина"?! Это не "ALT Sysadmin Tools" и 
>>> даже не "Regular Rescue". Если бы его добавили в отдельный 
>>> rescue.iso так, чтобы используя компоненты rescue*+* в 
>>> mkimage-profiles я мог не захватывать, например, eepm и recoll, то я 
>>> не был бы против. Т.е. если поместите в rescue+misc+extra, я за.
>>>
>>> Это небольшая, но тенденция, что есть инициаторы запихивания 
>>> несоответствующих пакетов в компоненты. Нескольких уже вынесли в 
>>> rescue+x11+extra, но приходилось тратить время на доказательство, а 
>>> это лишняя трата общего времени.
>>>
>>
>> Давайте тогда из pkg.in/lists/tagged/base+rescue уберём ещё и:
>>
>> # Package management
>> apt-repo
>> aptitude
> Я не против убирания aptitude. apt-repo можно для удобства оставить.
>
>> Зачем это в компоненте rescue?
> apt-repo может понадобиться в процессе установки доп.софта, а eepm 
> точно ничем не поможет.

Установки доп. софта в rescue ?

Re: [devel-distro] rescue швейцарский нож

[Vladimir D. Seleznev]

On Thu, Sep 23, 2021 at 11:16:38AM +0300, Anton Farygin wrote:
> On 23.09.2021 11:08, Sergey V Turchin wrote:
> > 23.09.2021 10:39, Антон Мидюков пишет:
> >> 23.09.2021 14:24, Sergey V Turchin пишет:
> >>> 22.09.2021 20:41, Vitaly Lipatov пишет:
> >>>
> >>> [...]
> >>>> Возможно, я не понял структуры, но можно всё же в инструменте для 
> >>>> сисадмина окажется epm?
> >>> Какой ещё "инструмент сисадмина"?! Это не "ALT Sysadmin Tools" и 
> >>> даже не "Regular Rescue". Если бы его добавили в отдельный 
> >>> rescue.iso так, чтобы используя компоненты rescue*+* в 
> >>> mkimage-profiles я мог не захватывать, например, eepm и recoll, то я 
> >>> не был бы против. Т.е. если поместите в rescue+misc+extra, я за.
> >>>
> >>> Это небольшая, но тенденция, что есть инициаторы запихивания 
> >>> несоответствующих пакетов в компоненты. Нескольких уже вынесли в 
> >>> rescue+x11+extra, но приходилось тратить время на доказательство, а 
> >>> это лишняя трата общего времени.
> >>>
> >>
> >> Давайте тогда из pkg.in/lists/tagged/base+rescue уберём ещё и:
> >>
> >> # Package management
> >> apt-repo
> >> aptitude
> > Я не против убирания aptitude. apt-repo можно для удобства оставить.
> >
> >> Зачем это в компоненте rescue?
> > apt-repo может понадобиться в процессе установки доп.софта, а eepm 
> > точно ничем не поможет.
> 
> Установки доп. софта в rescue ?

В текущий сеанс. Иногда бывает необходимость.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel-distro] rescue швейцарский нож

[Антон Мидюков]

23.09.2021 15:16, Anton Farygin пишет:
> On 23.09.2021 11:08, Sergey V Turchin wrote:
>> 23.09.2021 10:39, Антон Мидюков пишет:
>>> 23.09.2021 14:24, Sergey V Turchin пишет:
>>>> 22.09.2021 20:41, Vitaly Lipatov пишет:
>>>>
>>>> [...]
>>>>> Возможно, я не понял структуры, но можно всё же в инструменте для сисадмина окажется epm?
>>>> Какой ещё "инструмент сисадмина"?! Это не "ALT Sysadmin Tools" и даже не "Regular Rescue". Если бы его добавили в отдельный rescue.iso так, чтобы используя компоненты rescue*+* в mkimage-profiles я мог не захватывать, например, eepm и recoll, то я не был бы против. Т.е. если поместите в rescue+misc+extra, я за.
>>>>
>>>> Это небольшая, но тенденция, что есть инициаторы запихивания несоответствующих пакетов в компоненты. Нескольких уже вынесли в rescue+x11+extra, но приходилось тратить время на доказательство, а это лишняя трата общего времени.
>>>>
>>>
>>> Давайте тогда из pkg.in/lists/tagged/base+rescue уберём ещё и:
>>>
>>> # Package management
>>> apt-repo
>>> aptitude
>> Я не против убирания aptitude. apt-repo можно для удобства оставить.
>>
>>> Зачем это в компоненте rescue?
>> apt-repo может понадобиться в процессе установки доп.софта, а eepm точно ничем не поможет.
> 
> Установки доп. софта в rescue ?
> 

Вот. Я тоже не понимаю. Если apt-repo не лишний, то почему eepm лишний?
eepm может также манипулировать репозиториями, как и apt-repo.
Если мы хотим "чистую" компоненту rescue, то давайте уберём из неё всё функционально лишнее.

Управление пакетами не является необходимостью для компоненты rescue.
А для Rescue, как live, это нужно. Но в такой live утилиты для управления
пакетами должны попадать не через компоненту rescue. Не через её базовую часть.

Раз уж подняли тему разницы между Rescue, как live, и rescue как компоненты,
То нужно быть последовательными до конца :-)

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] rescue швейцарский нож

[Sergey V Turchin]

23.09.2021 11:40, Антон Мидюков пишет:

[...]
> Если мы хотим "чистую" компоненту rescue, то давайте уберём из неё всё функционально лишнее.
Согласен. А eepm и aptitude будет в списке rescue+pkginstall+extra, 
правильно?

[...]

-- 
Regards, Sergey

Re: [devel-distro] rescue швейцарский нож

[Sergey V Turchin]

23.09.2021 11:16, Anton Farygin пишет:

[...]
>> apt-repo может понадобиться в процессе установки доп.софта, а eepm 
>> точно ничем не поможет.
> 
> Установки доп. софта в rescue ?
Ничто не идеально. Завтра может появиться инструмент, который позарез 
всем понравится.

-- 
Regards, Sergey

Re: [devel-distro] rescue швейцарский нож

[Sergey V Turchin]

23.09.2021 11:40, Антон Мидюков пишет:

[...]
> почему eepm лишний?
Потому, что ни один человек в этом обсуждении пока так и не смог 
ответить мне, нафиг он там нужен.

[...]


-- 
Regards, Sergey

Re: [devel-distro] rescue швейцарский нож

[Антон Мидюков]

23.09.2021 17:29, Sergey V Turchin пишет:
> 23.09.2021 11:40, Антон Мидюков пишет:
> 
> [...]
>> почему eepm лишний?
> Потому, что ни один человек в этом обсуждении пока так и не смог ответить мне, нафиг он там нужен.

Ровно за тем же, зачем apt-get и apt-repo. Рулить репозиториями, пакеты устанавливать.
Есть привыкшие к epm пользователи.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] rescue швейцарский нож

[Антон Мидюков]

23.09.2021 17:24, Sergey V Turchin пишет:
> 23.09.2021 11:40, Антон Мидюков пишет:
> 
> [...]
>> Если мы хотим "чистую" компоненту rescue, то давайте уберём из неё всё функционально лишнее.
> Согласен. А eepm и aptitude будет в списке rescue+pkginstall+extra, правильно?
> 

Да.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] rescue швейцарский нож

[Konstantin Lepikhov]

Hi Антон!

On 09/23/2021, at 05:47:31 PM you wrote:

> 23.09.2021 17:29, Sergey V Turchin пишет:
> > 23.09.2021 11:40, Антон Мидюков пишет:
> > 
> > [...]
> >> почему eepm лишний?
> > Потому, что ни один человек в этом обсуждении пока так и не смог ответить мне, нафиг он там нужен.
> 
> Ровно за тем же, зачем apt-get и apt-repo. Рулить репозиториями, пакеты устанавливать.
> Есть привыкшие к epm пользователи.
Я привык к dpkg и zypper. Давайте их тоже поставим, а то это
дискриминация! :)

-- 
WBR et al.

Re: [devel-distro] rescue швейцарский нож

[Антон Мидюков]

23.09.2021 18:00, Konstantin Lepikhov пишет:
> Hi Антон!
> 
> On 09/23/2021, at 05:47:31 PM you wrote:
> 
>> 23.09.2021 17:29, Sergey V Turchin пишет:
>>> 23.09.2021 11:40, Антон Мидюков пишет:
>>>
>>> [...]
>>>> почему eepm лишний?
>>> Потому, что ни один человек в этом обсуждении пока так и не смог ответить мне, нафиг он там нужен.
>>
>> Ровно за тем же, зачем apt-get и apt-repo. Рулить репозиториями, пакеты устанавливать.
>> Есть привыкшие к epm пользователи.
> Я привык к dpkg и zypper. Давайте их тоже поставим, а то это
> дискриминация! :)
> 

Я не уверен, что они будут полезны в Альте в отличии от epm ;)

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] rescue швейцарский нож

[Konstantin Lepikhov]

Hi Антон!

On 09/23/2021, at 06:05:10 PM you wrote:

> 23.09.2021 18:00, Konstantin Lepikhov пишет:
> > Hi Антон!
> > 
> > On 09/23/2021, at 05:47:31 PM you wrote:
> > 
> >> 23.09.2021 17:29, Sergey V Turchin пишет:
> >>> 23.09.2021 11:40, Антон Мидюков пишет:
> >>>
> >>> [...]
> >>>> почему eepm лишний?
> >>> Потому, что ни один человек в этом обсуждении пока так и не смог ответить мне, нафиг он там нужен.
> >>
> >> Ровно за тем же, зачем apt-get и apt-repo. Рулить репозиториями, пакеты устанавливать.
> >> Есть привыкшие к epm пользователи.
> > Я привык к dpkg и zypper. Давайте их тоже поставим, а то это
> > дискриминация! :)
> > 
> 
> Я не уверен, что они будут полезны в Альте в отличии от epm ;)
Почему? А вот я уверен! (это я к качеству обсуждения и обоснования).

-- 
WBR et al.

Re: [devel-distro] rescue швейцарский нож

[Michael Shigorin]

On Wed, Sep 22, 2021 at 08:41:08PM +0300, Vitaly Lipatov wrote:
> >> Подтверждаю с мелкой поправочкой: alt-rescue -- это российский
> >> армейский нож, некоторые его даже как основу для кластерного
> >> бездискового образа применяли (применяют?).
> > Точно, образ! Вот и делайте образ. Отдельный. Зачем всем портить?

Соответственно и задачу по убиранию чего-либо, что тебе в _общих_
списках не нравится, стоит ставить внятно: мол, в отдельном
оставляйте, если вам надо, но ко мне чтоб не прилетало, не хочу.

[*]

> > Не путайте, пожалуйста образ Rescue с компонентой rescue.
> Просветите для общего развития: как используется компонента
> rescue кроме как для создания образа rescue и почему сотня Кб
> bash-скрипта сравнивается с Plasma&LibreOffice?

Списки пакетов pkg.in/lists/tagged/*rescue* в mkimage-profiles
и впрямь более широко применимы, чем для alt-rescue.iso --
в т.ч. rescue+base идёт как основа спасательного "кусочка"
дистрибутивных исошек (могут задействоваться и другие).

Вообще говоря, это давным-давно предусмотренная в m-p ситуация;
возможно как форкнуть список пакетов или иной "кирпичик",
если изменения существенны и их направление явно иное, чем
у имеющегося -- так и "вычесть" из имеющегося списка, добавив
точечно в те места, где список используется, а убранное
из общего в конкретном действительно нужно.

См. тж.:
http://altlinux.org/mkimage-profiles/howto#Обобщаем_в_метапрофиль

PS: пока вспомнил -- в m-p есть скриптик bin/pkgdups,
вдруг кому ещё пригодится; звать удобно так:

$ make -C pkg.in/lists pkgdups

> Возможно, я не понял структуры, но можно всё же в инструменте
> для сисадмина окажется epm?

Для этого его достаточно включить в RESCUE_PACKAGES
в цели distro/regular-rescue из conf.d/regular.mk :-)

* э, а так и я могу сказать: зачем в общем alterator-vm
воткнули пример vm-profile.scm с LVM?  Вам нравится --
в образе и делайте, а мне эта глюкалка и даром не нужна:
http://bugzilla.altlinux.org/37569

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] rescue швейцарский нож

[Michael Shigorin]

On Thu, Sep 23, 2021 at 10:24:37AM +0300, Sergey V Turchin wrote:
> Это небольшая, но тенденция, что есть инициаторы запихивания
> несоответствующих пакетов в компоненты. Нескольких уже вынесли
> в rescue+x11+extra, но приходилось тратить время на
> доказательство, а это лишняя трата общего времени.

Братцы, ставьте в копию при необходимости, постараюсь помочь.

За всеми интересными рассылками следить уже не успеваю :(

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] rescue швейцарский нож

[Michael Shigorin]

On Thu, Sep 23, 2021 at 03:40:49PM +0700, Антон Мидюков wrote:
> >>> Давайте тогда из pkg.in/lists/tagged/base+rescue уберём ещё и:
> >>> # Package management
> >>> apt-repo
> >>> aptitude
> >> Я не против убирания aptitude. apt-repo можно для удобства оставить.
> >>> Зачем это в компоненте rescue?
> >> apt-repo может понадобиться в процессе установки доп.софта,
> >> а eepm точно ничем не поможет.

Точно так же может помочь.

> > Установки доп. софта в rescue ?
> Вот. Я тоже не понимаю. Если apt-repo не лишний, то почему eepm
> лишний?  eepm может также манипулировать репозиториями, как и
> apt-repo.  Если мы хотим "чистую" компоненту rescue, то давайте
> уберём из неё всё функционально лишнее.

Ну конкретно это было бы из крайности в крайность, полагаю.

> Управление пакетами не является необходимостью для компоненты rescue.
> А для Rescue, как live, это нужно. Но в такой live утилиты для управления
> пакетами должны попадать не через компоненту rescue. Не через её базовую часть.
> 
> Раз уж подняли тему разницы между Rescue, как live, и rescue как компоненты,
> То нужно быть последовательными до конца :-)

Тут есть такие моменты, как мне кажется (далее банальности):

- важен здравый смысл выпускающего (как образы, так и m-p):
  если компонент рекурсивно невелик, полезен и не вреден,
  порой недооценен (малоизвестен при своей полезности) --
  его может иметь смысл положить даже тогда, когда вроде бы
  прямого отношения не имеет, как минимум в конкретный образ
  (я так когда-то клал xpra в regular-icewm, например,
  хотя это ближе к крайности);

- если есть несколько близких по функциональности аналогов,
  класть по умолчанию стоит тот, который или лучше по сумме
  характеристик, или имеет минимальную сумму проблем;

- если возникают споры -- пусть даже о вкусах -- стоит стараться
  их разрешить конструктивно: в том числе для этой технической
  возможности я во многом и делал mkimage-profiles, чтоб _разные_
  задачи получалось по большей части решать на _совместно_
  развиваемом наборе "кирпичиков".

Если понадобится такие споры разрешать -- не стесняйтесь
привлекать: не первый десяток лет исошки собираю,
вдруг выйдет сообща найти хорошее решение.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] rescue швейцарский нож

[Sergey V Turchin]

23.09.2021 15:24, Michael Shigorin пишет:

[...]
>>>> apt-repo может понадобиться в процессе установки доп.софта,
>>>> а eepm точно ничем не поможет.
> Точно так же может помочь.
Если точно так же, то он уже лишний.

[...]
>> apt-repo.  Если мы хотим "чистую" компоненту rescue, то давайте
>> уберём из неё всё функционально лишнее.
> Ну конкретно это было бы из крайности в крайность, полагаю.
Ну да. Костыли -- наше всё, а правильное -- крайность. ;-)

[...]

-- 
Regards, Sergey

Re: [devel-distro] rescue швейцарский нож

[Vitaly Lipatov]

Konstantin Lepikhov писал 23.9.21 14:00:
> Hi Антон!
> 
> On 09/23/2021, at 05:47:31 PM you wrote:
> 
>> 23.09.2021 17:29, Sergey V Turchin пишет:
>> > 23.09.2021 11:40, Антон Мидюков пишет:
>> >
>> > [...]
>> >> почему eepm лишний?
>> > Потому, что ни один человек в этом обсуждении пока так и не смог ответить мне, нафиг он там нужен.
>> 
>> Ровно за тем же, зачем apt-get и apt-repo. Рулить репозиториями, 
>> пакеты устанавливать.
>> Есть привыкшие к epm пользователи.
> Я привык к dpkg и zypper. Давайте их тоже поставим, а то это
> дискриминация! :)
dpkg и zypper будут достаточно бесполезны, но вот epm старается 
поддерживать их параметры. Просто вместо dpkg или zypper (а также urpmi 
или dnf) пишите epm.
Но вы ёрничаете.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel-distro] rescue швейцарский нож

[Konstantin Lepikhov]

Hi Vitaly!

On 09/23/2021, at 06:50:08 PM you wrote:

> Konstantin Lepikhov писал 23.9.21 14:00:
> > Hi Антон!
> > 
> > On 09/23/2021, at 05:47:31 PM you wrote:
> > 
> >> 23.09.2021 17:29, Sergey V Turchin пишет:
> >> > 23.09.2021 11:40, Антон Мидюков пишет:
> >> >
> >> > [...]
> >> >> почему eepm лишний?
> >> > Потому, что ни один человек в этом обсуждении пока так и не смог ответить мне, нафиг он там нужен.
> >> 
> >> Ровно за тем же, зачем apt-get и apt-repo. Рулить репозиториями, 
> >> пакеты устанавливать.
> >> Есть привыкшие к epm пользователи.
> > Я привык к dpkg и zypper. Давайте их тоже поставим, а то это
> > дискриминация! :)
> dpkg и zypper будут достаточно бесполезны, но вот epm старается 
> поддерживать их параметры. Просто вместо dpkg или zypper (а также urpmi 
> или dnf) пишите epm.
> Но вы ёрничаете.
dpkg не бесполезен - если его поставить, в .deb можно ковыряться через mc.
Вот вам и test case, прошу добавить dpkg в rescue!

-- 
WBR et al.