(В ответ на комментарий №0)
> kworkstation.mk
Остальное в http://git.altlinux.org/people/zerg/packages/?p=mkimage-profiles-kworkstation.git;a=tree;h=refs/heads/kworkstation-master

В p8 m-p надо бы тоже обновить (пока не разъезжалось), но наработки/исправления идут сперва в сизиф.

Не так уж важно, откуда и куда идут сперва. Главное, чтоб в p8 пришли.

(В ответ на комментарий №0)
> Created an attachment (id=6839) [details]
> kworkstation.mk
Сейчас уже запушен текущий вариант.

Разобрался (быстрей было бы с REPORT=1 и build/targets.dot):
у тебя mixin/kworkstation-common-deps сперва дёргает use/syslinux/ui/gfxboot,
а потом -- более базовую use/live/x11, где цепочка зависимостей выглядит так:
use/live/x11 -> use/live/base -> use/live/.base -> use/syslinux/ui/menu

Решение -- поставить кобылу впереди телеги, бишь поднять строчку с use/live* выше строчки с use/syslinux/ui/gfxboot

В mkimage-profiles здесь проблема в том, что make каждой цели достигает лишь единожды, успешно достигнутая цель далее игнорируется.  Раньше на это напарывались в основном при конфигурировании загрузчика, что и документируется в features.in/bootloader/README

А так это баг в mkimage-profiles-kworkstation

(В ответ на комментарий №5)
> Решение -- поставить кобылу впереди телеги, бишь поднять строчку с use/live*
> выше строчки с use/syslinux/ui/gfxboot
Разбираться, кто на ком стоял -- проблема mkimage-profiles.

Created attachment 6869 [details]
поменял порядок строк (патч проверен)

Ещё раз: вследствие ограничений использованного инструментария (make) есть такая особенность mkimage-profiles; можно написать свой DSL (как давно предлагает Чеусов), но у такого подхода свои проблемы -- начиная с необходимости разучивать как минимум синтаксис ещё одного языка.

Напарываются на него крайне редко, видимо, потому, что в основном народ тоже строит дома с фундамента, а не с крыши ;-)

(В ответ на комментарий №7)
> Напарываются на него крайне редко, видимо, потому, что в основном народ тоже
> строит дома с фундамента, а не с крыши ;-)
Это потому, что черепицу сложно спутать с кирпичом. ;-)

(В ответ на комментарий №7)
> Created an attachment (id=6869) [details]
> поменял порядок строк (патч проверен)
Спасибо, работает!

(In reply to comment #9)
> (В ответ на комментарий №7)
> > Created an attachment (id=6869) [details] [details]
> > поменял порядок строк (патч проверен)
> Спасибо, работает!

Ну, если так, --  тогда закрывайте.

(В ответ на комментарий №10)
> Ну, если так, --  тогда закрывайте.
Это не исправление, а обход. Но уже не блокер.

Переименую, пожалуй.

(В ответ на комментарий №12)
> Переименую, пожалуй.
Значит, ты всё же не понял comment 7. :(

---
Обратите внимание: в процессе конфигурирования дистрибутива
"переключение" загрузчика может происходить только в одну сторону
-- если выставлен grub, произведено переключение на lilo и затем
произведена ещё одна попытка переключения на grub, то в конфигурации
останется lilo как последняя "новая" цель с точки зрения make.

При необходимости всё-таки "пересилить" последнее изменение можно

        @$(call set,BASE_BOOTLOADER,grub_или_lilo)
--- features.in/bootloader/README

Не надо менять заголовок "Зависимости между компонентами не строятся должным образом".

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

P.S.
Ты создал эти определения и единственный знаешь все их зависимости. Бегать постоянно по куче Makefile-ов и смотреть, кто на ком стоял меня и без этого уже достало.

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

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

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

(В ответ на комментарий №15)
Майк, не ломай заголовок. Я повесил баг и мне виднее.

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

(В ответ на комментарий №16)
> Я повесил баг и мне виднее.
Раз тебе виднее, ты с ним и сиди, а я пошёл.

Слив засчитан.