LFS 10.0

эх… попробовать чтоли хоть раз. Чисто для себя

Я последний раз четверку собирал :) Дооолгоооо

а сколько времени ушло?

LFS - это, конечно, очень хороший дистрибутив, но если достаточно ядерной консоли с локалью KOI8-R.

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

дни...

эх… попробовать чтоли хоть раз. Чисто для себя

А смысл?…

Делать больше нечего, ядро и тулчейн собирать… Можно уж просто накатить base от Арча, а дальше собирать под ними прикладной софт как хочется.

А что это даст? Ну соберу я сам всё тот же дистрибутив с системд и буду работать на нём точно также. Толку? Только мучиться с каждым обновлением.

Этот дистр «академический» и интересует только «академиков».

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

А что это даст?

Таких кто этого не сделает хоть раз - не возьмут в космонавты! lfs даёт хорошее представление об устройстве системы - как оно в нутрях. Кто не собирал lfs тот не могёт считать полноценных (половозрелым!) линуксойдом! :D

Да ерунда.

Что мне даст знание того, какие зависимости добавили или удалили в очередной версии базовых программ?

Сборка и так понятная:

Сначала минимальный тулчейн, аналогично как для кросскомпиляции под другую архитектуру. Потом сборка libc, сборка нормального тулчейна, сборка ядра. Перезагрузка. Сборка всего остального.

Если собирать всё точно также как в бинарных дистрибутивах, то, конечно, и разницы не будет.

Разница будет если нужно компилять всё со своими уникальными опциями, но при этом не хочется тратить силы и время на опакечивание этого всего. При этом появляется возможность вручную управлять каждым файлом в системе и никто не будет ругаться на то, что, якобы, куда-то подевались файлы каких-то пакетов.

Понятное дело, что не всем это нужно.

Да, сверхчастотным индуктором тоже можно отстрелить себе ногу, но место ему в лабалатории. А автор топика удивляется почему об LFS никто не написал. Никто же не постит новости про LIMO и прочую экзотику лабалаторного назначения?

Разница будет если нужно компилять всё со своими уникальными опциями, но при этом не хочется тратить силы и время на опакечивание этого всего.

Лол. Ну если начинать с дебиана и им же заканчивать, то понятно, почему люди боятся пакетов.

А в нормальных системах пакеты просто рецепты воспроизведения сборки, упрощающие жизнь.

Что тут сложного?

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

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

Что тут сложного?

Вы когда-нибудь писали слакбилды/ебилды/.spec-файлы/etc?

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

%files
%doc README COPYING CREDITS CHANGES
%{_bindir}/%{name}
%{_bindir}/bmore
%{_bindir}/bvedit
%{_bindir}/bview
%{_datadir}/%{name}/
%{_mandir}/man1/*.1.*

Сколько-то пакетов создать, конечно, вполне можно, но чтобы одному человеку с нуля самому опакетить целый дистрибутив...

Вы когда-нибудь писали слакбилды/ебилды/.spec-файлы/etc?

Писал.

А они сами себя не напишут и их надо писать для каждого пакета.

А простыни для сборки LFS писать не надо? Или предлагаете все команды вручную набивать в терминал в качестве альтернативы?

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

Это проблема? Не указывайте:

depends=()
makedepends=()

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

Вас заставляют что ли вписывать все поля рецепта?

но и перечисляя вообще все файлы пакета

/me крутит пальцем у виска.

При этом, по хорошему, части путей к файлам надо ещё заменять на макросы. Наподобие такого:

Я вам выше ссылку дал. Найдите там «перечисление всех файлов пакета» и «макросы».

Это полный рецепт без изъятий. Пишется за 10 минут по образцу.

Сколько-то пакетов создать, конечно, вполне можно, но чтобы одному человеку с нуля самому опакетить целый дистрибутив…

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

Или предлагаете все команды вручную набивать в терминал в качестве альтернативы?

Да, я про такую быструю сборку и говорил. Этот вариант также подходит для обновления уже собранного LFS'а. Однако, если юзер каждый раз заново пересобирает систему без обновлений предыдущих сборок, то он, конечно, может написать себе соответствующие скрипты.

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

Половина дня на базовую систему параллельно с другими делами. На всё остальное расчёт сил и времени зависит от кол-ва этого всего остального.

Да, я про такую быструю сборку и говорил.

Быстрая она только в мечтах мамкиных хакеров и тех, кто этим ни разу не занимался.

А так как я занимался сборкой тулкита для кросскомпиляции, то знаю, какой это геморрой.

Этот вариант также подходит для обновления уже собранного LFS’а. Однако, если юзер каждый раз заново пересобирает систему без обновлений предыдущих сборок …

cd $packagename && makepkg -i

Хоть с обновлениями, хоть с пересборкой, как угодно.

…может написать себе соответствующие скрипты.

Угу. Берём core репозиторий Арча или любого другого дистра. Выкидываем лишнее, добавляем патчи и опции сборки по желанию. Запускаем сборку. ВНЕЗАПНО получаем ту же самую «LFS», но ради которой не нужно неделю красноглазить в консоли.

Половина дня на базовую систему параллельно с другими делами …

… и это делается для того, чтобы?

Для того, чтобы что?

Полдня потратить на то, что за 2 минуты делается при помощи pacman -S base — это всё потому, что…

Для того, чтобы что?

Для того, чтобы получить минималистичную систему без лишнего в ней и со своими особенными опциями сборки.

Для того, чтобы получить минималистичную систему без лишнего в ней …

pacman -S base

… и со своими особенными опциями сборки.

yaourt -G $packagename
cd $packagename
vim PKGBUILD
makepkg -i

А есть еще crux.

Ну или собрать генту.

В общем, ответа так и не услышал.

Иногда даже Гента недостаточно гибкая. Не говоря уже о том, сколько пришлось бы красноглазить с другими дистрибутивами.

Понятное дело, что далеко не все сталкиваются с такими случаями.

Иногда даже Гента недостаточно гибкая.

Ну так перепиши пару ебилдов, епта…

Понятное дело, что далеко не все сталкиваются с такими случаями.

Хотелось бы услышать эти случаи.

Есть даже специализированные решения для развёртывания кросскомпиляции и сборки всякой эмбедщины.

В разработке дураков нет вручную собирать поставляемую ОС (это малая проблема) и контроллировать результаты (вот где проблема!).

Не всегда достаточно переписать пару ебилдов.

Лично я, например, сидел в своей сборке на основе LFS'а, когда сидел в ядерной консоли с локалью KOI8-R.

А потом я опять запустил иксы и ушёл с LFS'а, да.

LFS -> Slackware -> Mageia

Обычно LFS на Slackware как раз и собирается. Ты вернулся в утробу, а от туда в... ? :-))

Я, кстати, ставил LFS с родного LiveCD в 2007-м году. А потом только обновлял.

После 2007-го года проект LFS'а, да, перестал развивать свой LiveCD.

ftp://ftp.lfs-matrix.net/pub/lfs-livecd/

с локалью KOI8-R

С разморозкой. Давно уже utf-8 имеется.

lfs ─ ~ ─ 
└$ cat /etc/lsb-release 
DISTRIB_ID="Linux From Scratch"
DISTRIB_RELEASE="SVN-20191108"
DISTRIB_CODENAME="v01z"
DISTRIB_DESCRIPTION="Linux From Scratch"
┌lfs ─ ~ ─ 
└$ locale
LANG=ru_RU.UTF8
LC_CTYPE="ru_RU.UTF8"
LC_NUMERIC="ru_RU.UTF8"
LC_TIME="ru_RU.UTF8"
LC_COLLATE="ru_RU.UTF8"
LC_MONETARY="ru_RU.UTF8"
LC_MESSAGES="ru_RU.UTF8"
LC_PAPER="ru_RU.UTF8"
LC_NAME="ru_RU.UTF8"
LC_ADDRESS="ru_RU.UTF8"
LC_TELEPHONE="ru_RU.UTF8"
LC_MEASUREMENT="ru_RU.UTF8"
LC_IDENTIFICATION="ru_RU.UTF8"
LC_ALL=
┌lfs ─ ~ ─ 
└$ каля-баля
bash: каля-баля: команда не найдена
┌lfs ─ ~ ─ 
└$

А толку от UTF-8 когда из-за ограничений ядра в шрифт для ядерной консоли больше чем 256 символов не запихать? Только всё в квадратиках становится.

А так выставляешь KOI8-R - и квадратики исчезают.

Попробовал сейчас забить полэкрана кириллицей. 256 символов там точно есть, а вот квадратиков почему-то нетуть. Как починить?

ограничений ядра

Что за ограничение? Может, у меня его нет?

Да не на длину строки ограничение, а на кол-во символов в шрифте.

У всех есть с давних времён.

/*
 *  Font switching
 *
 *  Currently we only support fonts up to 32 pixels wide, at a maximum height
 *  of 32 pixels. Userspace fontdata is stored with 32 bytes (shorts/ints, 
 *  depending on width) reserved for each character which is kinda wasty, but 
 *  this is done in order to maintain compatibility with the EGA/VGA fonts. It 
 *  is up to the actual low-level console-driver convert data into its favorite
 *  format (maybe we should add a `fontoffset' field to the `display'
 *  structure so we won't have to convert the fontdata all the time.
 *  /Jes
 */

#define max_font_size 65536

kmscon

kmscon

Его нет в LFS'е. Там только ядерный tty с растровыми шрифтами в PSF формате.

Лапками….

Нет, конечно, можно собрать LFS, а потом поставить поверх kmscon. Только это будет уже сборка на основе LFS'а. А если юзер просто соберёт LFS, то никакого kmscon'а у него не будет. Да и не всем он нужен.

Сколько-то пакетов создать, конечно, вполне можно, но чтобы одному человеку с нуля самому опакетить целый дистрибутив...

что в этом сложного? Ах да, время! У меня на это ушло пара месяцев(один раз), зато потом только мелкие исправления, а так собирай себе в удовольствие хоть через день.

Хвастаться неосиляторством - фу таким быть. Там всего-то - LFS+BLFS(вместе с иксами и свистоперделками) 1100 с хвостиком пакетов и то с учётом multilib'а.