LINUX.ORG.RU

Какие есть альтернативные деревья portage?

 , ,


1

4

В связи с тем что в portage за последние 10 лет прибыло много пакетов, работа с ним сильно затрудняется. Есть ли какие-нибудь проекты по разбиению дерева на части, чтобы не хранить информацию о тех пакетах, которые никогда не будут установлены и не тратить часы на расчёт зависимостей, подключив лишь нужные овелреи?
Я бы например хранил крупные DE вроде gnome, kde в оверлеях, что позволило бы подключить только нужные оверлеи или даже сделать оверлей к примеру с gnome2, если потребовалась софтина из тех времён не ломая остальное.
Ну или просто альтернативное дерево, в котором меньше шелухи.

★★★★★

Ответ на: комментарий от Gentooshnik

Я как-то прочитал https://ru.wikipedia.org/wiki/Funtoo и из-за этого:

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

подумал что там наоборот всё хуже
Попробую поставить

mittorn ★★★★★ ()
Ответ на: комментарий от Gentooshnik

Разделить то они разделили, а можно ли отключить десктопные оверлеи не понятно

mittorn ★★★★★ ()

Клонишь гитом, ставишь sparse checkout, профит

annulen ★★★★★ ()

чтобы не хранить информацию о тех пакетах, которые никогда не будут установлены

При синхронизации через rsync можно выкинуть неинтересные тебе категории пакетов(или отдельные пакеты). Об этом в Gentoo Handbook к слову написано как минимум с 2009(а то и раньше).

Вопрос целостности дерева при этом - на твоей совести. То есть, например, выкинуть из дерева всё KDE(если ты им не пользуешься) - вполне себе рабочая идея. А вот выкинуть, например, gtk или qt - уже сложнее, тут надо быть по-настоящему тулкитофобом.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от anonymous

Там по дефолту systemd. Задолбаюсь выпиливать

mittorn ★★★★★ ()
Ответ на: комментарий от macumazan

Устарело. Теперь аналогично прописывается в repos.conf

anonymous ()
Ответ на: комментарий от Pinkbyte

А вот выкинуть, например, gtk или qt - уже сложнее, тут надо быть по-настоящему тулкитофобом.

Не так сложно, есть же юзы, которые решают задачу почти целиком. А вот выкинуть какие-нибудь либы — это вообще за гранью фантастики.

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

r3lgar ★★★★★ ()
Ответ на: комментарий от adminlinwin

Сначала он был мне интересен, однако когда попытался поставить днобиан с ним на своё ядро - не взлетело. Неоправданные требовпния к ядру - наверно главный аргумент против systemd для меня. Ещё можно добавить сложность настройки и то что к нему железно приаязываются программы. Зачем-то libsystemd сделали shared библиотекой, когда можно было код взаимодействия с systemd держать хидером или мелкой static либой. Зачем-то пихнулм всё в init когда можно было там оставить только управление демонами и устройствами, как в android init.

mittorn ★★★★★ ()
Ответ на: комментарий от mittorn

а что с ядром не так?

вылизанная x86 гента с ядром в котором каждый параметр проверен и перепроверен, чтобы ни лишнего модуля ни байта - грузится до десктопа минуту, после загрузки занимает 150mb оперативы
arch x64 со сток ядром грузится до десктопа 5 секунд, после загрузки занимает 250mb оперативы

и вот ради этих 100mb разницы я тратил(с 2001) уйму времени и электричества на конпеляние софта в генте, а потом оказалось, что в arch, chromium устанавливается 2 минуты вместо 2-ух часов и remmina с deadbeef нормально выглядят без лишних телодвижений )

adminlinwin ()
Ответ на: комментарий от adminlinwin

после генты не мог поверить что так бывает

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

r3lgar ★★★★★ ()
Ответ на: комментарий от r3lgar

ты, в генте уйму времени потратил на это, а я, в арче - нет

adminlinwin ()
Ответ на: комментарий от mittorn

В gentoo убрали юзфлаги gtk2/gtk3, даже если приложение умеет gtk2

Никто не запретит мне переписывать ебилды прямо в /etc/portage/env/${CATEGORY}/${PACKAGE}! :3

r3lgar ★★★★★ ()
Ответ на: комментарий от adminlinwin

Там армовое ядро было и в конфиге не было кучи опций, без которых оно не работало. Для меня конечно не проблема пересобрать ядро, но зачем?

mittorn ★★★★★ ()
Ответ на: комментарий от mittorn

я пока всего лишь месяц на arch'e и мои arm'ы всё ещё на gentoo, но имхо и это поправимо - gentoo там не нужно, имхо достаточно будет и openwrt

adminlinwin ()

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

Умножая знания…

Так вот проектов таких в gentoo, насколько я знаю, нет. Движется она по тому-же направлению - "одно дерево это модно, молодёжно, эти идиоты-юзеры ничего не нарукожопят и всё всегда под рукой". Поменяли только способ доставки. Точнее даже не поменяли а расширили - к существовавшим вариантам добавили git и выпилили чейнжлоги.

Мало того я ещё в 2014м году посчитал практическое ускорение от дерева портежей с количеством ebuild-ов равным количеству ebuild-ов в stage3 по сравнению с официальным на тот момент см Portage тормоза уже неторт! а основная ссылка перенесена туда Оценка влияния количества ebuild-ов в дереве на скорость выполнения emerge.

Я бы например хранил крупные DE вроде gnome, kde в оверлеях, что позволило бы подключить только нужные оверлеи или даже сделать оверлей к примеру с gnome2, если потребовалась софтина из тех времён не ломая остальное.

Нельзя вот так просто взять и разделить на части то, что уже больше десятка лет пилилось как единое целое. К примеру gtk - куда его относить?

А всем кто советует нечто я бы настоятельно порекомендовал основываться на личном мнении и опыте а не слушать что вам вешают на уши… И да далее я основываюсь на своём опыте а не на слухах или чьих-то мнениях.

Paludis поддерживает работу в gentoo в качестве основного менеджера пакетов. При этом необходимо только насоздавать его конфигов. Однако, насколько я понял, в этом случае он работает со структурой дерева портежей gentoo и gentoo-шными ebuild-ами а не c exherses из exherbo. Не знаю будет ли работать paludis на gentoo с деревом exherses из exherbo но подозреваю что скорее всего не будет. И соответственно это тоже тупиковый вариант. Да и смысл если есть exherbo?

exherbo - документация потрачена чуть менее чем полностью, образцово показательный и мёртвый, чуть менее чем совсем, irc канал. К примеру stage3 уже давно идёт с systemd по умолчанию в то время, как в документации встречаются сказки ещё про openrc когда он был основным и/или про выпиливание systemd когда на него ещё не была завязана вся их система. Из плюсов да действительно дерево там минимальное и всё вынесено в оверлеи. Из минусов - я не отношу себя к части слепоглухонемых рукожопов… Однако неспешная сборка ЭТОГО в chroot-е показала что лучше всё-же остаться на gentoo пусть и со всеми её минусами.

funtoo - сборочка даниэльки и его компании. Цели не ясны. Задачи не определены. Подводных камней дохренища. Как вам к примеру заявление САМОГО на старом форуме сабжа "funtoo дистрибутив не для десктопа… десктоп на GNU/Linux удел кучки дебилов а лично у меня десктоп на Mac OS"? Надо ли говорить что вскоре после этого был устроен апдэйт форумного движка и всё эти старые перлы/лулзы портёрли вместе со старой базой данных???

Немного истории. Вышеозвученная цитата всплыла после того, как не один десяток юзеров funtoo насоздавал похожих топиков смысл которых сводился к состоянию дел с актуальным десктопным ПО gnome/kde в сабже.

А дело это было так - funtoo форкнуло portage и gentoo-шные профили, в которых были свои собственные, отличные от гентушных, версии тулчейна и всё неугодное левой пятке САМОГО либо хардмаскалось либо вовсе удалялось из дерева. Ко всему этому, по хорошему, надо было-бы пилить и полностью своё собственное дерево portage однако это-же долго, муторно и вообще "у нас мало разработчиков«… поэтому они не долго думая стали поверх официального дерева portage из gentoo мержить свои велосипедики. И приводило это к забавному - зачастую даже при наличие необходимых ebuild-ов в дереве портежей funtoo и gentoo-шных оверлеях собрать/обновить что-либо было невозможно из-за неудовлетворённых либо замаскированных либо попросту удалённых зависимостей. Нужно ли говорить что всё это говно многих достало и основательно выбесило? Примерно в тот момент я и дропнул funtoo хотя и был на ней с её основания. И нет никаких весомых оснований полагать что сейчас в политике funtoo что-либо поменялось и/или разработчиков стало в разы больше и/или ebuild-ы у них абсолютно всё свои собственные а не идут прямиком из gentoo.

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

имхо в 2018 уже не нужны ни Gentoo, ни его бессмысленные инсталяторы типа Funtoo, ни его бессмысленные бинарные клоны типа Calculate

adminlinwin ()
Ответ на: комментарий от init_6

в 2018, более эффективней отдать ресурсы ПК на майнинг, чем на бессмысленную и беспощадную компиляцию

adminlinwin ()
Ответ на: комментарий от mos

Эти же вопросы те же 10 лет назад возникали...

Эти вопросы возникают с постоянной периодичностью. В одной из очередных таких итераций и был рождён тот-же exherbo. А смешной здесь ты.

init_6 ★★★★★ ()
Ответ на: комментарий от mittorn

Просто потому что всё время дерево было чуть более раздутым чем нужно и всё время это напрягало

Выкинуть неинтересные тебе части дерева не составляет труда. В конце концов оно сейчас в git и можно форкать и делать с ним всё что твоёй душе угодно. К примеру тот-же gnustep-* можно выпилить вообще без каких-либо негативных последствий.

Главная печаль заключается в том, что вот это самое минимальное дерево его можно создать с очень большими натяжками… Дело в том, что минимальным его не даст сделать сам portage который по зависимостям проверит и потянет ВСЁ хочешь ты этого или нет. А чтобы получить значительный эфект от того самого ускорения одним удалением gnustep-* здесь не обойтись.

Дальше ещё есть такая проблема - в дереве хоть и используется git применяется он исключительно как средство доставки и не более. Поясню подробнее. У нас всегда есть стабильная и нестабильная ветки у нас есть куча поддерживаемых архитектур со своими, пусть и незначительными, отличиями. В конце концв у нас есть пакеты актуальные исключительно под некую не сильно распространённую архитектуру и нигде более. И ну казалось бы почему не сделать хотя-бы стабильный и нестабильный branch? Это сразу уменьшит количество пакетов минимум примерно вдвое что уже само посебе немало. Печальные времена настанут только для тех, кто смешивал ветки… Но нельзя приготовить амлет не разбив яйца.

Немаловажная проблема заключается в том что и куда отнести. Вон выше Pinkbyte примерно об этом уже говорил. К примеру gtk+. При всей очевидости его принадлежности к gnome всё же настолько повростал во многий софт что по факту он скорее некий общий компонент. Либо вместе с минимальным деревом в любом случае из-за gtk+ люди будут вынуждены таскать и оверлей gnome.

init_6 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.