layman overlay gentoo | работа с локальными репозиториями
HTML-код
- Опубликовано: 12 сен 2024
- emerge -qav layman
Убедимся, что настройки верны в файле layman.cfg, есть переменная
repos_conf : /etc/portage/repos.conf/layman.conf
После выполним команду: layman-updater -R
layman -a tarantool
Размаскируем:
emerge --autounmask tarantool
и добавим в файл:
/etc/portage/package.accept_keywords/tarantool
=dev-db/tarantool-2.4.1.1 ~amd64
Отключить overlay:
layman -d tarantool
Пора пилить плейлист для gentoo =)
Если честно, то я даже не знаю что еще такого показать особенного, чем кардинально отличается gentoo от других осей.
Если только ebuild написать.
@@itgod ну во первых: уже 7 видео.
Во вторых: всегда интересны грабли и заблуждения, которые могут помешать сходу понять и правильно воспринять систему и как следствие - с ней работать. Пример описанного - забивать отвёрткой гвозди. Также, наоборот, интересны и сами концепции, которые положены в дистрибутив. Хотя бы обзорно. Вот это всё и можно вкратце осветить.
Тут я сразу скажу что я ещё не все видосы посмотрел, у меня это дело запланировано на ближайшее время, когда буду ставить gentoo к себе на домашнюю лабу в один из выходных. Хотя, учитывая текущие обстоятельства (приключения с LXC), возможно, что сделаю это гораздо раньше.
В третьих: на первый взгляд и между CentOS и Debian не много различий, но потом оказывается что у них сеть по разному настраивается, разное отношение к /usr, разное к /lib. Да и /bin, и /sbin, и /usr/bin, и /usr/sbin - не те что прежде. И /tmp у них по разному чиститься. Набор базового софта вроде и одинаковый, но всётаки разный. Вроде systemd и там и там, но в дебиане оно урезано. Вообще, кстати, "эволюция" дистрибутивов может быть темой для видео.
Эх Эгорка...
Можешь сеть настраивать как хочешь, nmcli, да хоть на баше скрипт написать.
Да я не спорю, что у rh /etc/sysconfig/network-manager
а у deb /etc/network/interface
что то, что то используют iproute2.
А вот касаемо /sbin, /usr/sbin
что там поменялось? Я что-то не заметил кардинальных изменений, расскажешь дураку? Есть стандарт который слава тебе ктулху ни кто не трогает и называется он FHS.
@@itgod дистриб - это программная и конфигурационная обвязка вокруг ядра. Так то для настройки сети можно и в /proc руками ковыряться. Только это уже уровень не дистриба, а ядра.
Да, по бинам подскажу. Теперь это не папки, а ссылки.
/bin -> usr/bin
/sbin -> usr/sbin
.
Тоже самое с lib:
/lib -> usr/lib
/lib64 -> usr/lib64
.
т.е. в CentOS ясно прослеживается тенденция уезда в сторону /usr. При этом где-то в документации они указывали что не гарантируют работу /usr на отдельном разделе. Так что теперь, если положить /usr на отдельную партицию и она не примонтируется, то будет потерян доступ как до рабочих программ, так и до утилит необходимых для исправления ситуации.
Ну это же не новость!
Вспоминаем реализацию библиотек, ранее была только директория /lib, после того как появилась возможность использования 64 битную архитектуру, разумеется встал вопрос именования бинарей, народ пошёл по пути наименьшего сопротивления, выбрав /lib64, так как многие работают с BSD стилем ( привычка ) используют usr/lib/, разумеется весь этот колхоз начал плодится и появился /usr/lib64, администрирование таких путей начинает захламлять систему, да ld_library_path ни кто не отменяет, особенно если использовать src ( сорсники ). Далеко ходить не надо, пример Solaris, закончилась лицензия, всё ставим из tarball.
А так как prefix и остальные параметры - народ не заморачивается, ставит аля:
./configure
make && make install
То разумеется, в последующем с такой помойкой как-то разгребаться надо, искать опять же библиотеки для сборки, кто куда положил - это занимает уйму времени, так что с симлинками работать проще и правильней.
А касаемо монтирования, ну ок, вынести var в отдельный раздел, а потом ошибись во fstab, будут теже яйца - вид с боку!
Так что в данном смысле, я полность согласен с разработчиками.
Аналогично с использованием директории sbin под запуск приложений.