debian: список зависимостей
Уважаемые! Как в дебиане построить список _установленных_ пакетов с их зависимостями в виде дерева?
Re: debian: список зависимостей
apt-cache depends `dpkg -l | awk »` 2>/dev/null
Re: debian: список зависимостей
dpkg --list показывает все установленные пакеты. dpkg --status пакет показывает подробную информацию о пакете, в том чисте и зависимости: dpkg --status apache2 Package: apache2 Status: install ok installed Priority: optional Section: web Installed-Size: 64 Maintainer: Debian Apache Maintainers Architecture: all Version: 2.2.3-4+etch4 Depends: apache2-mpm-worker (>= 2.2.3-4+etch4) | apache2-mpm-prefork (>= 2.2.3-4+etch4) | apache2-mpm-event (>= 2.2.3-4+etch4) Description: Next generation, scalable, extendable web server Apache v2 is the next generation of the omnipresent Apache web server. This version - a total rewrite - introduces many new improvements, such as threading, a new API, IPv6 support, request/response filtering, and more.
Похожие темы
- Форум дерево зависимостей (2011)
- Форум Дебианщики откликнитесь (2002)
- Форум Список зависимостей (2008)
- Форум Linux from scratch, дерево зависимостей (2017)
- Форум Кластер (2000)
- Форум suffix tree vs trie (2013)
- Форум список файлов (2005)
- Форум [поиск зависимостей] Полуночный опрос (2008)
- Форум Графическая карта зависимостей для RPM пакетов (2012)
- Форум Вывести список установленных пакетов (2011)
Linux from scratch, дерево зависимостей
Там большое количество пакетов, и если собирать, например, кеды, то приходится долго переходить со страницы на страницу, собирая софт по зависимостям.
Существует ли способ как-то построить и визуализировать дерево зависимостей?
Тогда было бы легче — выбрал например какой-то пакет, и собираешь по очереди все от чего он зависит.
Ты же понимаешь, что такие порочные мысли ведут к очевидной цепочке gentoo -> arch/аналог -> ubuntu/аналог.
Да, никто не мешает его водрузить на LFS.
Deleted ( 10.01.17 10:48:26 MSK )
Последнее исправление: Deleted 10.01.17 10:49:16 MSK (всего исправлений: 1)
Для portage надо будет делать свое дерево ебилдов?
Мне кажется, что portage усложнит систему. А ведь плюсом LFS является простота.
Для portage надо будет делать свое дерево ебилдов?
Если ты хочешь собрать LFS, а не Gentoo, то да.
А ведь плюсом LFS является простота.
Рано или поздно такая простота доводит до проблем с простатой.
фу таким модератором быть! 🙂
Поздравляю, ты дошёл до мысли о пакетном менеджере.
Единственным плюсом LFS является понимание что у тебя в системе и как. Для повседневного использования LFS не подходит без долгих часов превращения в аналог генты или арча.
В воиде как-то умеют строить деревья зависимостей. Можно поинтересоваться как именно они это делают, есть есть желание.
ну как, очевидно XBPS система сборки его и строит.
Так и до пакетного менеджера недалеко.
А ведь плюсом LFS является простота.
очевидно, что нет
он дошел до мысли, что 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 в лфс ни слова. А в редхатокнижке это есть.
А редхатокнижки — тебе деталей дистрособирания не расскажут.
Когда я разбирался с embedded несколько лет назад, в lfs я подглядывал в части понимания как строить минимальную систему.
Продолжай. Только не забывай, что, раз «Единственным плюсом LFS является понимание что у тебя в системе и как», то, очевидно, в LFS должна быть какая-то информация о ред хате, которой в самой документации редхата получить нельзя, ведь понимание что и как у тебя в _LFS_ системе плюсом назвать нельзя — LFS самими авторами не позиционируется, как система для daily use.
эм.. LFS это не учебник, а практическое пособие
сменить libc, openssl, пакетный менеджер, систему инициализации, да даже tty и т.д. и т.п. тем самым получить свою ОС на ядре линукс, а не редхат\gentoo\ubuntu
или у вас там в методичке написано «тупой копипаст команд из лфс книжки в консоль с минимальной нагрузкой на межушный ганглий» — значит так оно и есть?
system-root ★★★★★ ( 10.01.17 13:44:52 MSK )
Последнее исправление: system-root 10.01.17 13:52:19 MSK (всего исправлений: 1)
Когда я разбирался с embedded несколько лет назад, в lfs я подглядывал в части понимания как строить минимальную систему.
Конкретнее. Какая именно информация оттуда была взята? Особенно это интересно в свете того, что LFS даже близко не является минимальной системой и для эмбеда (это там, где BB, musl, вырезание доков и примеров из стандартной поставки и т.д.) не подходит в принципе.
Пробовал? Ну там сменить glibc на musl и собрать blfs?
У меня для тебя плохие новости — там нет пакетного менеджера. Совсем.
ОМГ, где «там»? в «дистрибутиве LFS» штоле?
реально, методичек начитаются.
а если кто-то напишет на пистоне пакетный менеджер на базе подписанных loop контейнеров в свой уютный LFS? не? нету такого пункта в методичке?
а если кто-то напишет на пистоне пакетный менеджер на базе подписанных loop контейнеров в свой уютный LFS?
То у этого кого-то появится пакетный менеджер в дистрибутиве на базе LFS. В самом LFS никаких пакетных менеджеров нет.
LFS это не учебник, а практическое пособие
дистрибутиве на базе LFS
И ты, и ты тоже можешь начитаться
а, спасибо, теперь я точно узнаю что это такое — «база LFS», а то вообще не пойми что обсуждали
ок, не вопрос, в твоей голове это фигня которую копипастят тупые с минимальной нагрузкой на меж..чёто-там и получают «базу LFS» aka готовый «дистрибутив LFS», главное я понимаю, чтоб они правильно копипастили, они ж все тупые
последний вопрос: зачем столько текста, если на главной http://linuxfromscratch.org можно было бы скрипт^W iso образ и кнопку donate только оставить? под разные архитектуры сразу. углублю — и еще линк на LFS Administration Guide
system-root ★★★★★ ( 10.01.17 14:23:55 MSK )
Последнее исправление: system-root 10.01.17 14:25:40 MSK (всего исправлений: 1)
последний вопрос: зачем столько текста, если на главной http://linuxfromscratch.org можно было бы скрипт^W iso образ и кнопку donate только оставить?
Не знаю. Скоро 7 лет, как я буду задаваться таким же вопросом — Весна, любовь. (комментарий) и далее по треду
но и совершенно не понимаешь, как устроена твоя система
детская травма же, очевидно, Ватсон
засим тему ненужности LFS с вами закрываем
system-root ★★★★★ ( 10.01.17 14:46:16 MSK )
Последнее исправление: system-root 10.01.17 14:46:37 MSK (всего исправлений: 1)
Я не собирал lfs для embedded, а подглядывал в книгу на предмет организации дистрибутива при самосборе. Хотя LFS не был единственным источником инфы. Я много чего тогда смотрел.
В продакшен пошёл уже подпиленый buildroot.
Dark_SavanT ★★★★★ ( 10.01.17 15:11:18 MSK )
Последнее исправление: Dark_SavanT 10.01.17 15:13:31 MSK (всего исправлений: 1)
Так про любой дистр сказать можно.
man DP: compositor, visitor
Можно. Но подходит только crux.
Я забросил LFS как только мой прототип менеджера пакетов стал развиваться в сторону портажа. Как сидел на генте, так и продолжаю сидеть (а LFS где-то должен валяться в недрах моей файлопомойки ещё).
Штатного пакетного менеджера нет.
Поэтому как раз таки один из вариантов — ставить софт в отдельные директории, а потом править переменные окружения.
А вообще тут вариантов куча) Можно собирать бинарные архивы, как в слаке. Можно установить какой-то пакетный менеджер из известных, например dpkg, а потом собирать деб-пакеты.
Я спросил тут про зависимости, так как думал, что может можно обойтись без пакетного менеджера, может где-то существует какая-то база данных по зависимостям, вне дистрибутивов.
Ведь мейнтейнеры дистров как-то же расставляют зависимости.
И выкинули бы. Если б всё что придумано после него не страдало недостатками в тех местах где у autotools проблем не было. C autotools худо бедно может померяться только cmake. Остальные — это лютый трешак.
Говорю о программах на «никому не нужных» C/C++.
В том же проекте на питоне, например, если мне кто-то посоветует заюзать autotools, я буду смотреть на него с недоумением.
Да хер бы с ней, травмой. Но вы на пару с Dark_SavanT и в этом треде, ровно также, как и никто в предыдущих, так и не назвали конкретной инфы из LFS, которая конкретно полезна и не дублируется манами. Только некоторое абстрактное «помогает лучше понять». Что понять? В какой системе? Чем лучше манов? Нет ответа.
Существует ли способ как-то построить и визуализировать дерево зависимостей?
А я и не говорил что там зарыто некое сакральное знание. В своё время ковыряясь с конкретной задачей, написанное в LFS мне оказалось полезным. Возможно не именно в LFS, а в CLFS или тому подобном.
Dark_SavanT ★★★★★ ( 10.01.17 23:36:47 MSK )
Последнее исправление: Dark_SavanT 10.01.17 23:38:18 MSK (всего исправлений: 1)
Единственным плюсом 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% (ноут/рабстанция), а ты что-ли таки перешла на воид?
Существует ли способ как-то построить и визуализировать дерево зависимостей?
Построить и визуализировать способов есть множество, но забивать данные (зависимости между пакетами) всё равно придётся самому руками
Похожие темы
- Галерея Linux From Scratch x86_64 (2013)
- Форум FreeBSD from scratch? (2019)
- Галерея Linux From Scratch (2010)
- Форум дерево зависимостей (2011)
- Статьи Funtoo from Scratch (2022)
- Форум DE from scratch (2013)
- Форум Linux from scratch (2005)
- Форум cpu from scratch (2009)
- Новости Linux From Scratch 7.5 (2014)
- Новости Linux From Scratch 7.3 (2013)