LINUX.ORG.RU
решено ФорумTalks

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

 


0

1

Например, есть у нас sys-fs/udev. В каталоге sys-fs лежит каталог udev с файлами. Но почему не сделали sys/fs/udev, что давало бы возможность делать сколько угодно подкатегорий, хоть sys/fs/udev/eudev? Интересует, какими причинами обусловлен этот выбор.

Заранее благодарю.

★★★★★

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

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

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

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

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

# cast Pinkbyte

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

qnikst ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 2)

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

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

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

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

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

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

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

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

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