Почему в генте пакеты имеют один уровень категории?

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

Вот я и спрашиваю, в каком именно месте необходима предсказуемая инерархия? Есть какие-то утилиты, которым необходима статическая глубина в 1 категорию?

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

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

Но это все домыслы, мне бы хотелось услышать кого-то из участников проекта gentoo.

# cast Pinkbyte

Потому что согласно тому же Gentoo Development Guide - Ebuild File Format формат всего дерева там category/name/name-version.ebuild

И список официальных собственно вот category

Остальное см man ebuild и man portage

ненужное переусложнение.

Это я понял, но _почему_ так сделано? Для чего специально отменили дерево и сделали двухуровневый формат? Что это дает?

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

нет оно предсказуемо и описано в стандарте.

ИМХО проще и логичнее было бы использовать стандартную неограниченную вложенность.

предложи измениния в PMS. А вообще не проще и не логичнее.

Категории изначально древовидные в представлении человека. Переусложнение — ставить на них ограничения. Я хочу понять, какая практическая польза от данных ограничений.

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

описано в стандарте

Да блин. Зачем на вопрос «почему так сделано» отвечать «потому что так сделано»? Очевидно, что стандарт описывает решение разработчиков, а не решение разработчиков продиктовано стандартом.

понижает сложность алгоритмов

Каким образом? На одну строчку вызовы рекурсии меньше?

увеличивает удобство поддержки юзеру и девам

Опять же, в чем?

Категории изначально древовидные в представлении человека.

нет. а может теги лучше ввести?

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

Создание единой не противоречивой иерархии это переусложнение. Ты лучше скажи какая польза от твоего предложения.

ты сказал «непредвиденное поведение», я тебе ответил, поведение будет предвиденное и описано в стандарте. Очевидно, что твой комментарий не связан с твоим вопросом.

Ты лучше скажи какая польза от твоего предложения.

Я уже сказал. Можно указать пакету любое количество подкатегорий. games/rpg/roguelike/nethack например, или www/browser/mozilla/adblock.

Это я понял, но _почему_ так сделано?

А что нелогичного в самом простом категория/название ? Собственно сделать иерархию сложнее не сильно большая проблема. Единственное - А зачем это ненужное усложнение?

А, ок. Неправильно понял твой ответ.

А что нелогичного в самом простом категория/название ?

Мне кажутся нелогичными категории вида net-www, net-im. Типа это разные категории, хотя на самом деле это подкатегории категории net. Я хз, есть ли в портеже такой функционал, но можно было бы поставить например пакеты из категории net в случае необходимости. Или сделать вместо сета kde категории de/kde/startkde, de/kde/fullkde и ставить все пакеты из них.

Можно указать пакету любое количество подкатегорий.

Сейчас все четко определено на уровне category/name/name-version.ebuild в случае же «любого количества» заранее неизвестного числа подкатегорий при этом еще и не имеющих стандартных принципов наименования…

Я вангую что современная скорость работы portage будет казаться просто сказкой!

Да, насчет скорости работы согласен. Теперь понятна причина.

Да, насчет скорости работы согласен. Теперь понятна причина.

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

скорее отсутсвие логичного правила создания иерархии.

Да, я понял. Это замедлит расчет зависимостей и работу портежа в принципе.

Это причина того, что скорость понизится. Само по себе отсутствие правило не такая большая проблема.

а net/www/ или www/net а личкрафты куда бросить? ты перепиши всю структуру портажей, так, чтобы с тобой согласились хотя бы трое.

И еще тонкий момент - вот сейчас category/name/name-version.ebuild вполне допускает одинаковые имена но в разных категориях и в таком случае portage просит имя целиком вместе с категорией. А в твоем случае нужно будет каждый раз точно писать emerge = sys/fs/udev/udev-version иначе вовсе не факт что где то еще, к примеру в virtual/udev, нет пакета с именем udev.

А это извини но таких же ненормальных как ты мало.

нет, это причина, что без eix вообще шансов найти что-либо не будет а ещё писать keyword вида category/*.

Потому что все взяли с фряхи. Сравни:

cd /usr/ports
make search name=gcc
cd devel/gcc-4.7.0

emerge -S gcc
emerge -pv gcc

Они могли засчет универсального emerge сделать иерархию какой угодно глубины. Но видимо решили не ломать традиции :)

а net/www/ или www/net а личкрафты куда бросить?

Сейчас же не спорят, бросать в www-net или в net-www. Или от смены уровня вложенности мейнтейнеры внезапно сойдут с ума и начнут перемещать все куда попало? :)

А в твоем случае нужно будет каждый раз точно писать emerge = sys/fs/udev/udev-version

А сейчас нужно писать =sys-fs/udev-version. Разница только в том, писать слеш или дефис.

А сейчас нужно писать =sys-fs/udev-version. Разница только в том, писать слеш или дефис.

Неет разница в том, писать иногда и для некоторых или ВСЕГДА и ДЛЯ МНОГИХ(еси не всех) !

т.к. в категории a-b гораздо меньшее пространство для возможностей и как следствие проще прийти к соглашению, ты это переопределенные системы уравнений не решал? типа 6 неизвестных и ~15000 уравнений, инетересный опыт, чтобы понять проблематику :)

причем профита особого в многоуровневости нет.

P.S. да вообще профита нет.

Скорее решили не ломать логику.

Меня тоже это всегда удивляло.

Это я понял, но _почему_ так сделано? Для чего специально отменили дерево и сделали двухуровневый формат? Что это дает?

ebuild'ы однотипные, потому что всегда категория/пакет, а не в каком-то случае категория/подкатегория/пакет/подпакет. Предсказуемость потому что.

А потом что, ставить пакеты набирая кучу категорий и подкатегорий?

По-моему у них вполне логичная система. И вроде как eudev не является подпакетов udev, это же замена, не? Зачем ему тогда лежать в другом пакете, который он должен _замещать_ ? Вот это точно нелогично.

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