Авто LFS

"Кроме
того, инструментарий я устанавливал не в /usr а в /opt. Мне так захотелось."
А почему /opt, а не /tpo или не /pto?

т.е. я типа как могу собрать одним скриптом ЛФС, или просто набор полезных тулзов? Спасибо, вобщем за ссылку, забукмаркал это дело, повожусь потом.

Если не секрет, почему взяли именно pkgtools? Хотя для такого малюсенького дистибутива можно и pkgtools :))

> А почему /opt, а не /tpo или не /pto?

Ты о такой штуке как FHS вообще слышал?

/opt This directory should contain add│]on packages that contain static files.

└▐└└└─ └y└x man hier
└└└p└{, └{ └┐└r└u└t└u└~└y└░...
└{ └├└┌└p└x└u "└}└~└u └└└p└{ └x└p└┤└─└└└u└|└─└┐└▌"

Эк его покорежило-то...
/opt This directory should contain add?on packages that contain static files.
это к фразе "мне так захотелсь"

LFS есть конечно гут, тока жАлательно к нему портаже ставить джентувский а то гемор будет долгий

очередной форк?
а смысл?
типа - не умею переводить, буду читать всякий левяк?
имхо - не знаешь английского, что бы поставить lfs - нечего вообще делать в *никсах

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

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

>LFS есть конечно гут, тока жАлательно к нему портаже ставить джентувский а то гемор будет долгий

А чем это будет отличаться от Gentoo собранного из stage1? :)

ИМХО LFS хорош просто поиграться, посмотреть как все устроено, но для реального использования мало пригоден, т.к. обновление через пол года будет не самой приятной процедурой... Или предложите его опять пересобирать с нуля? А скрипты делающие все автоматом, вообще ИМХО бесполезны, т.к. теряется основное достоинство, не надо самому копаться. Хотя когдато мне в голову тоже приходила такая мысль (но посмотрела, никого и ушла :D).

А какой смысл от LFS, собранного не руками?

в разделе ссылок:
"DirectFB - это понятно"

как правило ссылки приводят не для того, чтобы похвастать тем, что тебе понятно, а для того, чтобы объяснить что-то непонятное другим :)

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

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

Батяня ?

Лично для меня и для моей работы есть очень большой смысл в LFS собранным полностью скриптом ))) Автору спасибо, хотя к сожалению эту же работу уже проделали

http://lfs.osuosl.org/alfs/news.html

> очередной форк? а смысл?

IMHO форкать LFS надо, но совсем с другой целью.

1) Сейчас они используют linux-2.6.x и udev (и при этом еще не перешли на скриптлеты в /etc/dev.d). Конфигурация слишком экспериментальная для использования на рабочей машине, и даже содержит известные неисправимые баги. Кроме того, сборка с чистым NPTL не будет работать в UML или Xen. LFS до 5.x включительно был передним краем стабильной технологии, а не передним краем науки о сборке Linux и его клонов, и потому к этим версиям LFS данное возражение не относится.

Тем, кто будет говорить про терпимость багов на десктопе: даже дом поросенка должен быть крепостью.

2) Сейчас разработчики LFS (особенно Unstable) плюют на BLFS (в IRC говорят: "я к BLFS никакого отношения не имею"). В свою очередь, BLFS следит за LFS Testing и плюет на Unstable. В сочетании с тем, что перенос новшеств из Unstable в Testing происходит без согласования с редакторами BLFS, имеем классическую модель водопада в разработке, со всеми ее негативными последствиями. Разделения на LFS и BLFS быть не должно - либо BLFS следует использовать в качестве основы свою собственную копию LFS вместо официальной.

3) Прогресса с интернационализацией в LFS не будет. Они просто отказываются что-либо добавлять, поскольку не могут это проверить и поскольку считают, что это будет тормозить процесс за счет опасения что-либо нечаянно незаметно испортить. Сейчас позиция на IRC: don't report any bugs since we won't fix them. (впрочем, есть инакомыслящие, что радует)

4) Инструкций по настройке софта в LFS нет. Везде, где только можно, конфигурация минимальная, и не всегда правильная. Однако известно, что наибольшую трудность вызывает именно правильная настройка, а не сборка.

Вспомните, что еще полтора года назад в их FAQ про "less prints <AD>" упоминалась установка LESSCHARSET, а не локали. За такое преступление русского на LOR просто убили бы.

Кроме того, они сейчас в BLFS в /etc/profile.d имеют скрипт tinker-term.sh, единственное назначение которого - замена TERM=xterm на TERM=xterm-color. По уму такое решается правильной настройкой ncurses в момент сборки перед командой ./configure (в файле даже комментарий по этому поводу есть):

sed -i -e '/^xterm|/,+1s,^\(.use\)=xterm-r6,\1=xterm-xfree86,' misc/terminfo.src

С таким "синдромом конфигурации по умолчанию" и сборкой ради сборки надо бороться.

5) То же самое относится к слепому использованию последних непропатченных версий как "самых лучших". Это просто не всегда верно. Вспомните хотя бы про глюки комбинации Qt 3.2.0 + KDE 3.1.5, которая тем не менее попала в книгу.

Мне одному, однако, провернуть такой проект не под силу. Если Вы согласны с написанным выше и желаете помочь (с пользой для себя), пишите: patrakov собака ums точка usu точка ru. Одно "маленькое" требование во избежание повторения ошибки (5): наличие времени и желания читать списки рассылки разработчиков софта, который есть в книге, а также рыться в чужих Bugzilla'х.

-- А. Е. Патраков

P.S.: LFS все еще является единственным дистрибутивом, который нормально документирует свои решения о сборке софта (command explanations).

интересно.
с многим согласен.
почти все самостоятельно правил при борке своего lfs (в данный момент использую ОЧЕНЬ сильно видоизменный 5.1)
с идеалогией комманды lfs согласен не везде, считаю, что с момента 4.0 она сильно пострадала
но я не за форк lfs, отдельный от основного проекта, мне кажеться более правильным присоединиться к основному проекту и развивать в нем идеи
ближайщий месяц я врядли смогу это сделать, а потом с радостью бы занялся

Ну, кто не знает, Александр Патраков, самый главный от России в LFS. Всё что он сказал верно. Более того, массу всего сделал полезного и не только в LFS.(Если не ошибаюсь, что-то было ещё для spectrum/a. :) ) Для меня вот ценнно его руководство конфигурации ncurses и соответственно правильной русификации mc.

Так же, я могу ошибаться, но вроде бы, Александр собирался бросить LFS, но, видимо, задержался... :)

-ден :)

"Рио-де-жанейро, Шура, моя хрустальная мечта и не лапайте ее своими волосатыми лапами" (с) Бендер

А что где-то в LFS сказано собирать точно так а не иначе ? Или религия запрещает при сборке вставлять свои ключики ? Или ./configure --help ориентируясь на установленную $LFS перестает работать ?

2fortl <очередной форк?

Это просто ПРИМЕР проделанной работы.

<у меня LFS тоже совсем не похоже на то, что предлогается на оригинальном сайте

А где ПРИМЕР твоего варианта?

<гораздо полезнее для потомства (и для своей практики английского) было бы перевести шестой бук

Ну он от пятого не очень сильно отличается. Разницу понять можно и без детального перевода.

<а все что не нравиться - обсудить на РОДНОМ сайте/в рассылке и пр.

Он все таки английский, а этот на русском.

2Swappp <А скрипты делающие все автоматом, вообще ИМХО бесполезны, т.к. теряется основное достоинство, не надо самому копаться Любо такой готовый скрипт все равно надо проверять на состав требуемых пакетов, версии пакетов и нужные опции сборки для своих целей. Так что свмому покопаться прийдется. А когда настроиш все под свои запросы, то потом можно только вырезать фрагмент по конкретному пакету, скопировать этот фрагмент в другой файл, изменить версию пакета на другую и запустить. Количество ручной работы минимально. Соответственно минимальна возможность внести ошибку при вводе. Ну и время набора руками ВСЕХ требуемых команд при сборке на много больше операции копирования.

Для anonamoz (*) (17.01.2005 22:14:41): почему взяли именно pkgtools? Он простой, маленький, не тянет за собой разных баз данных, как RPM, используется в стандартном дистре, да и разобраться мне с ним было проще и быстрее, чем с другими.

Каминский С.

> Или религия запрещает при сборке вставлять свои ключики?

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

RPM тянет только одну - BerkeleyDB. Самое отвратное, что заставить ее юзать системную крайне тяжко.

> свои ключики я вставлю, если я знаю, что мне это надо

Так о чем речь? Ведь сборка LFS строго по книге - это дефолт, который можно менять под свои нужды, да и форкать BLFS смысла тоже нет, поскольку его необходимость вообще под большим вопросом, хотя присутствуют ознакомительные нужды в плане зависимостей, поскольку спрашивать у каждого пакета от кого он зависит жестко от кого мягко, и потом докачивать необходимые сырцы - малость ломает.

>даже дом поросенка должен быть крепостью.

Классный аргумент! ;-)) Постараюсь запомнить... )))