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

Gentoo'шник - следствие детской психической травмы?


0

1

В качестве предисловия один очень правильно поставленный вопрос, который и мне хотелось бы задать гентушникам:

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


(C) system-root

Я заметил, что пользователи Gentoo ранимее пользователей других дистрибутивов. Вы такого не замечали? Просто ну реально - ведь как ни ставь груду программного обеспечения, всё равно в итоге получится примерно одно и тоже, а зачастую вообще приходится ставить тот или иной дистрибутив только потому, что в нём нужную (целевую) программу установить проще или она работает лучше...
Пользователи Ubuntu, Mandriva, AltLinux, Fedora, OpenSuSE любят свои дистрибутивы, но такого ярого оголтелого фанатизма не наблюдается, напротив - есть и самокритичность, и переходы между дистрибутивами. Но Gentoo - словно какой-то тапир или священная корова, неприкасаем, складывается впечатление, что пользователи его как в одной из серий Южного Парка папа Стэна - в буквальном смысле рожают в муках, а потом защищают как собственное дитя. А может быть это связано действительно с последствиями каких-то детских травм?

Понимаете... тут суть в том, что я не представляю начальника, который даёт сисадмину задание: скомпиль мне на том вон серваке world, обычно ставится задача вроде: «подготовь платформу для тестирования бизнес-приложения N, требования такие-то... и чтоб через 3 часа к обеду всё было, [а не то пасть порву, премии лишу и буду смотреть волком]»
Соответственно, люди, сохнущие по Gentoo, видимо, не совсем работой занимаются... Или я «как всегда» что-то не так понимаю?

★★★★★

Последнее исправление: DRVTiny (всего исправлений: 3)
Ответ на: комментарий от qnikst

>а так тебе ответили и сразу стало видно, кто адекватен, а кто нет :)

Дооо, это такой адекват, что прям ппц просто, главное - всё слошь аргументированно по существу. Я прям даже думаю книгу написать с золотыми с цитатами. Будет называться «Молодёжный экстремизм или бытовой фашизм в интернет».

А на микроскоп обидаешься, потому что сам также юзаешь? В 99 случаях из 100 тупой emerge и в 1 случае может быть полезешь в ebuild, потому что его кто-то через Ж написал? Скажите, дядя, а чем это принципиально отличается от установки rpm-пакетов, а?

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

1s%слошь%сплошь%; 4s%обидаешься%обижаешься%

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

> Я прям даже думаю автобиографию написать с золотыми с цитатами. Будет называться «Молодёжный экстремизм или бытовой фашизм в интернет».

напрашивающаяся поправка

А на микроскоп обидаешься, потому что сам также юзаешь?

В 99 случаях из 100 тупой emerge и в 1 случае может быть полезешь в ebuild, потому что его кто-то через Ж написал?

о да, а у LXF-щиков в 99 случаях тупой configurmakemakeinstall и только в 1 случае из 100 полезет ковырять make файлы, т.к. его кто-то криво написал.

Скажите, дядя, а чем это принципиально отличается от установки rpm-пакетов, а?

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

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

>о да, а у LXF-щиков в 99 случаях тупой configurmakemakeinstall и только в 1 случае из 100 полезет ковырять make файлы, т.к. его кто-то криво написал.

Это взрыв мозга какой-то, я не понял смысл фразы.

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


Если это src.rpm, то отличие в том, что yum не умеет ставить зависимости для src.rpm (вроде бы, может, уже и умеет), в остальном абсолютно тоже самое, только ещё приятные плюшки в виде готовых бинарных пакетов получишь.
Если rpm (те самые бинарники), то соответственно нет стадии сборки.
Так что да, отличий по сути минимум. Но если вообще всё ставить из исходников, то emerge удобнее понятно. Другое дело - зачем это самое всё собирать? Чаще всего нужно проконтролировать сборку 2-х-3-х, ну пусть даже 10-ка основных программ каких-то, а вот зачем их полтысячи пакетов так собирать или даже больше... То есть если ты реально разработчик оно и понятно, а так мне кажется тюнинг системы через /etc/sysctl.conf намного эффективнее. А ещё эффективнее наверное отказ от X'ов с клиент-серверной архитектурой в пользу чего-то более приземлённого...

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

> Это взрыв мозга какой-то, я не понял смысл фразы.

это калька с твоей фразы про emerge, говорящая о том, что для того чтобы использовать emerge не надо лезть в каждый ebuild, а так же, что если человек использует emrge - то это не значит, что он досконально шарит в системе. Сравнивается это с тем, что даже если использовать связку configure-make-make-install то всё равно ни в исходный код, ни в сам makefile никто заглядывать не будет. Хотя в общем-то, наверное, справедливо можно отметить, что уровень знаний по неспециализированным пакетам среднего гентушника будет повыше, чем у многих других дистрибутивов.

Если это src.rpm, то отличие в том, что yum не умеет ставить зависимости для src.rpm (вроде бы, может, уже и умеет), в остальном абсолютно тоже самое, только ещё приятные плюшки в виде готовых бинарных пакетов получишь.

в спек файлах там зависимости точно прописаны и енмип ставятся.

Так что да, отличий по сути минимум. Но если вообще всё ставить из исходников, то emerge удобнее понятно. Другое дело - зачем это самое всё собирать? Чаще всего нужно проконтролировать сборку 2-х-3-х, ну пусть даже 10-ка основных программ каких-то, а вот зачем их полтысячи пакетов так собирать или даже больше...

Т.е. зависимости бинарных пакетов от конкретной версии библиотеки в бинарных дистрибутивах уже решены и я могу поставить любые подходящие под зависимости версии и у меня будет магический «revdep-rebuild», который сделает всё как надо? И добавление нового софта (не из репозиториев) тоже? И live версии программ и слежение за ними? И модели выбора реализации либы типа eselect и java/gcc-config для общесистемного и настройкки под конкретного юзера?

То есть если ты реально разработчик оно и понятно, а так мне кажется тюнинг системы через /etc/sysctl.conf намного эффективнее. А ещё эффективнее наверное отказ от X'ов с клиент-серверной архитектурой в пользу чего-то более приземлённого...

Вот разве прислушаться к тому, что генту это не только тюнинг настолько тяжело? :)

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

в спек файлах там зависимости точно прописаны и енмип ставятся.


Да, они прописаны, никто ж не спорит, но... кто их ставить-то будет? При попытке сборки rpmbuild'ом с отсутствующими зависимостями он вывалит список того, что не установлено и скажет «Да звидання!». А вот хочется-то поставить src.rpm yum'ом каким-нибудь или в случае AltLinux - apt-get'ом. Тока как... На самом деле я просто могу тупить в этом плане, потому что давно уже не занимался сборкой src.rpm'ок (по банальной причине того, что заколебёшься же переделывать спеки на свою структуру ФС). Сам я не так, чтобы горячо люблю лищние зависимости в rpm, но честно говоря при современных объёмах жёстких дисков мне уже по барабану, поставится там KDE вместе с каким-нибудь мелким парсером для XML-файлов или не поставится: даже для 250Гб винчестера это капля в море, а на скорость работы системы не влияет (если только на ls /usr/bin или ls -R /usr/lib).

Т.е. зависимости бинарных пакетов от конкретной версии библиотеки в бинарных дистрибутивах уже решены и я могу поставить любые подходящие под зависимости версии и у меня будет магический «revdep-rebuild», который сделает всё как надо? И добавление нового софта (не из репозиториев) тоже? И live версии программ и слежение за ними? И модели выбора реализации либы типа eselect и java/gcc-config для общесистемного и настройкки под конкретного юзера?


Кхм... Э... Мне короче надо, чтобы программы собирались в структуру аля

$SYS_APP_PREFIX/$Package/$Version/{Configuration,Binaries,DataFiles,Documentation,Development}
Ну и, например, Binaries:
$SYS_APP_PREFIX/$Package/$Version/Binaries/{lib,exe}
$SYS_APP_PREFIX/$Package/$Version/Binaries/exe/{demos,sys,tests}
Так можно?
То есть вот это вот перечисленное тобой оно тоже пригодится, но в моём случае хотелось бы сделать $SYS_APP_PREFIX в /opt и независимую версию в $HOME пользователя....

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

Кхм... Э... Мне короче надо, чтобы программы собирались в структуру аля

$SYS_APP_PREFIX/$Package/$Version/{Configuration,Binaries,DataFiles,Documentation,Development}
Ну и, например, Binaries:
$SYS_APP_PREFIX/$Package/$Version/Binaries/{lib,exe}
$SYS_APP_PREFIX/$Package/$Version/Binaries/exe/{demos,sys,tests}

Так можно?

wtf? особенно относится к Configuration,Binaries... тут запросы почище чем у мегабакса :)

Максимум чего ты можешь получить это собрать программу в другой DESTDIR, но у тебя будет обычная юниксовая раскладка файлов.

То есть вот это вот перечисленное тобой оно тоже пригодится, но в моём случае хотелось бы сделать $SYS_APP_PREFIX в /opt и независимую версию в $HOME пользователя....

Давай ты расскажешь, для чего тебе это надо и как ты видишь, что это будет адекватно работать, лично я не понимаю и не вижу ответов ни на один из вопросов. Единственный вариант решения, который я тут вижу это сделать такой набор пакетов, а потом для каждой программы делать sandbox и туда уже через линки (или ещё как) подсовывать соотвествующие либы и конфиги. Тогда поидее каждую программу можно будет настраивать «как-надо», а все либы будут храниться в общей куче и emerge будет следить за зависимостями. (Это всего лишь идея, которую я не уверен, что кто-либо когда-нибудь будет реализовывать)

P.S. в принципе я как-то интересовался, можно ли emerge'м ставить программы в HOME пользователя, и вроде даже варианты как сделать были, но я не осилил.

P.P.S. но при чём тут gentoo и сообщество? ;)

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