Re: [d-kernel] дальнейший распил firmware-linux

[Konstantin Lepikhov <lakostis@altlinux.org>]

Hi Michael!

On 12/06/2023, at 11:28:56 PM you wrote:

> 	Здравствуйте.
> "После распаковки потребуется дополнительно 345MB дискового пространства"
> и послужило причиной слазить в firmware-linux и посмотреть, чего там
> опять лишнего для подавляющего большинства наших систем.
> 
> В сборке 20231204-alt2, отправленной заданием #335975, выделены
> подпакеты qcom, mrvl, mellanox, отвечающие за три верхние позиции
> рейтинга местоядных:
> 
> e16c:/lib/firmware> du -sh * | sort -rh | head
> 159M    qcom
> 82M     mrvl
> 82M     mellanox
> 64M     nvidia
> 60M     amdgpu
> 44M     ath11k
> 31M     intel
> 30M     mediatek
> 26M     i915
> 21M     qed
> e16c:/lib/firmware> rpm -qf qcom              
> firmware-linux-20231115-alt2.noarch
> 
> В случае марвела с мелланоксом вынесены прошивки к свичам,
> которые вообще очень мало кому нужны (но мне были :)) --
> а в случае с квалкомом вынесены подкаталоги для платформ,
> бишь SoC, которые опять же нужны тем, кто соберётся делать
> образы конкретно для таких систем.
> 
> Заодно почистил Provides:/Obsoletes: пяти-десятилетней давности
> (см. тж. ALT#46206).
> 
> Следующим набегом хорошо бы разобрать amdgpu и nvidia,
> вот только тут уже думать надо будет и советоваться:
> есть мысль, что надо выделить метапакеты desktop и server,
> * под desktop утащить всё крупное про GPU и wifi,
> * под server -- про соответствующие HBA и NIC;
> * остальное содержимое унести в подпакет generic;
> * а сам firmware-linux сделать метапакетом,
> чтобы не менять ничего в сборке образов и обновлениях,
> но иметь возможность снести лишнее (и более вдумчиво
> распихивать по образам, когда дойдут руки и до них).
Это все экономия на спичках и создание проблем где их нет. Особенно,
когда каждое ядро версит по полгигабайта. Миша, тебе реально нечем
заняться?

> 
> Возможно, в некоторые подпакеты вроде qcom стоит добавить
> ExclusiveArch:, если это ровно одна архитектура -- тогда
> можно будет не зеркалить на любой другой, а размер репо
> будет тем же, что и в случае noarch (но тут вникать надо
> и это уже совсем мелочи).
> 

-- 
WBR et al.