Linux from scratch, дерево зависимостей

Ты же понимаешь, что такие порочные мысли ведут к очевидной цепочке gentoo -> arch/аналог -> ubuntu/аналог.

Тебе нужен portage.

Да, никто не мешает его водрузить на LFS.

Тебе нужен paludis.

Fixed for you bro.

Для portage надо будет делать свое дерево ебилдов?

Мне кажется, что portage усложнит систему. А ведь плюсом LFS является простота.

Для portage надо будет делать свое дерево ебилдов?

Если ты хочешь собрать LFS, а не Gentoo, то да.

А ведь плюсом LFS является простота.

Рано или поздно такая простота доводит до проблем с простатой.

фу таким модератором быть! :)

Поздравляю, ты дошёл до мысли о пакетном менеджере.

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

В воиде как-то умеют строить деревья зависимостей. Можно поинтересоваться как именно они это делают, есть есть желание.

В воиде как-то умеют

ну как, очевидно XBPS система сборки его и строит.

Так и до пакетного менеджера недалеко.

кеды

А ведь плюсом LFS является простота.

/0

очевидно, что нет
он дошел до мысли, что make, autoconf, automake ещё в прошлом веке нужно было выкинуть на помойку и создать нормальные инструменты
потому, что на фоне относительно «нормальных» систем автоматической сборки в относительно «современных» языках, эти древние артефакты могут вызывать только недоумение у людей в 2017 году
пакетный менеджер, лол.
будто в него зависимости сами попадают магически

make не надо. А вот autotools давно пора.

Единственным плюсом LFS является понимание что у тебя в системе и как

Какая такая сакральная информация идёт в LFS, чего нельзя узнать из Red Hat System Administrator's Guide ?

Red Hat System Administrator's Guide
LFS

дальше кэпствовать?

Только та, что ты делаешь всё руками и в теории начинаешь лучше понимать как устроен дистрибутив вообще.

А редхатокнижки - тебе деталей дистрособирания не расскажут.

CRUX смотрел? Это практически LFS + менеджер пакетов.

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

поносит autotools
на фоне относительно «нормальных» систем автоматической сборки

Об чем речь, уважаемый?

Только та, что ты делаешь всё руками и в теории начинаешь лучше понимать как устроен дистрибутив вообще

В теории — может быть, на практике — нет. Ибо тупой копипаст команд из лфс книжки в консоль с минимальной нагрузкой на межушный ганглий. Ну написано в лфс, что перед чрутом нужно сбиндить /dev и смаунтить proc в $LFS/proc, ну так это в любой доке по чруту говорится, а что такое proc или что будет, если не сбиндить /dev в лфс ни слова. А в редхатокнижке это есть.

А редхатокнижки - тебе деталей дистрособирания не расскажут.

LFS тоже.

Когда я разбирался с embedded несколько лет назад, в lfs я подглядывал в части понимания как строить минимальную систему.

дальше кэпствовать?

Продолжай. Только не забывай, что, раз «Единственным плюсом LFS является понимание что у тебя в системе и как», то, очевидно, в LFS должна быть какая-то информация о ред хате, которой в самой документации редхата получить нельзя, ведь понимание что и как у тебя в _LFS_ системе плюсом назвать нельзя — LFS самими авторами не позиционируется, как система для daily use.

редхатокнижке это есть

эм.. LFS это не учебник, а практическое пособие
сменить libc, openssl, пакетный менеджер, систему инициализации, да даже tty и т.д. и т.п. тем самым получить свою ОС на ядре линукс, а не редхат\gentoo\ubuntu
или у вас там в методичке написано «тупой копипаст команд из лфс книжки в консоль с минимальной нагрузкой на межушный ганглий» — значит так оно и есть?

Когда я разбирался с embedded несколько лет назад, в lfs я подглядывал в части понимания как строить минимальную систему.

Конкретнее. Какая именно информация оттуда была взята? Особенно это интересно в свете того, что LFS даже близко не является минимальной системой и для эмбеда (это там, где BB, musl, вырезание доков и примеров из стандартной поставки и т.д.) не подходит в принципе.

сменить libc, openssl

Пробовал? Ну там сменить glibc на musl и собрать blfs?

пакетный менеджер

У меня для тебя плохие новости — там нет пакетного менеджера. Совсем.

там нет пакетного менеджера

ОМГ, где «там»? в «дистрибутиве LFS» штоле?
реально, методичек начитаются...
а если кто-то напишет на пистоне пакетный менеджер на базе подписанных loop контейнеров в свой уютный LFS? не? нету такого пункта в методичке?

сменить glibc на musl

…и на генте можно.

а если кто-то напишет на пистоне пакетный менеджер на базе подписанных loop контейнеров в свой уютный LFS?

То у этого кого-то появится пакетный менеджер в дистрибутиве на базе LFS. В самом LFS никаких пакетных менеджеров нет.

реально, методичек начитаются...

И ты, и ты тоже можешь начитаться — http://linuxfromscratch.org/lfs/view/stable/

LFS это не учебник, а практическое пособие

дистрибутиве на базе LFS

facepalm-RELEASE-amd64-memstick.img

И ты, и ты тоже можешь начитаться

а, спасибо, теперь я точно узнаю что это такое — «база LFS», а то вообще не пойми что обсуждали
ок, не вопрос, в твоей голове это фигня которую копипастят тупые с минимальной нагрузкой на меж..чёто-там и получают «базу LFS» aka готовый «дистрибутив LFS», главное я понимаю, чтоб они правильно копипастили, они ж все тупые
последний вопрос: зачем столько текста, если на главной http://linuxfromscratch.org можно было бы скрипт^W iso образ и кнопку donate только оставить? под разные архитектуры сразу. углублю — и еще линк на LFS Administration Guide

последний вопрос: зачем столько текста, если на главной http://linuxfromscratch.org можно было бы скрипт^W iso образ и кнопку donate только оставить?

Не знаю. Скоро 7 лет, как я буду задаваться таким же вопросом — Весна, любовь... (комментарий) и далее по треду

но и совершенно не понимаешь, как устроена твоя система

детская травма же, очевидно, Ватсон
засим тему ненужности LFS с вами закрываем

Я не собирал lfs для embedded, а подглядывал в книгу на предмет организации дистрибутива при самосборе. Хотя LFS не был единственным источником инфы. Я много чего тогда смотрел.

В продакшен пошёл уже подпиленый buildroot.

Так про любой дистр сказать можно.

man DP: compositor, visitor

Можно. Но подходит только crux.

Тебе нужен portage.

++

Я забросил LFS как только мой прототип менеджера пакетов стал развиваться в сторону портажа. Как сидел на генте, так и продолжаю сидеть (а LFS где-то должен валяться в недрах моей файлопомойки ещё).

http://www.linuxfromscratch.org/lfs/view/stable/chapter06/pkgmgt.html

Штатного пакетного менеджера нет.

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

А вообще тут вариантов куча) Можно собирать бинарные архивы, как в слаке. Можно установить какой-то пакетный менеджер из известных, например dpkg, а потом собирать деб-пакеты.

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

Ведь мейнтейнеры дистров как-то же расставляют зависимости.

деревья зависимостей.

О боги. Как это развидеть?!

И выкинули бы. Если б всё что придумано после него не страдало недостатками в тех местах где у autotools проблем не было. C autotools худо бедно может померяться только cmake. Остальные - это лютый трешак.

Говорю о программах на «никому не нужных» C/C++.

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

детская травма же, очевидно, Ватсон

Да хер бы с ней, травмой. Но вы на пару с Dark_SavanT и в этом треде, ровно также, как и никто в предыдущих, так и не назвали конкретной инфы из LFS, которая конкретно полезна и не дублируется манами. Только некоторое абстрактное «помогает лучше понять». Что понять? В какой системе? Чем лучше манов? Нет ответа.

Существует ли способ как-то построить и визуализировать дерево зависимостей?

да, использовать генту

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

Единственным плюсом LFS является понимание что у тебя в системе и как

Не видел, не знаю. Но думаю эту же задачу прекрасно решает slackware. При этом не отказываясь от идеи пакетных менеджеров. Они здесь есть, но здесь нет болезни прочих дистров — попытки объять необъятное, в данном вопросе, глабоально решая проблемы зависимостей.

sqg тебе без проблем составит список зависимостей для конкретного пакета, а sbopkg без проблем траверсит эти списки. Но только для конкретного пакета. По прежнему имеешь чудную возможность отстрелить себе ногу, по прежнему вынужден знать что у тебя в системе и как, если хочешь улыбаться и иметь свободное время. Слака по прежнему не признает принципа «волшебной кнопки», порождающего проблемы которые не может решить ни эта же кнопка ни пользователь; по прежнему верна доктрине «Не знаешь — научим».

Какая такая сакральная информация идёт в LFS, чего нельзя узнать из Red Hat System Administrator's Guide ?

А что ты можешь узнать о линуксе из «Red Hat System Administrator's Guide ?» Из него ты можешь узнать только о systemd — как правильно просить эту обезьяну с напильником приспособить под твои нужды систему. Я не прав?

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

Спасибо, я пользуюсь void/gentoo — 25%/75% (ноут/рабстанция), а ты что-ли таки перешла на воид?

Существует ли способ как-то построить и визуализировать дерево зависимостей?

Построить и визуализировать способов есть множество, но забивать данные (зависимости между пакетами) всё равно придётся самому руками