exherbo/gentoo, отличия

В чём отличия написано у них на сайте, емнип. Основное - Paludis как пм.

Пользуясь случаем хочу спросить - использует ли кто-то этот paludis? Как оно, долго ли настраивать, много ли багов? Есть ли реальный прирост в том же расчёте зависимостей?

да, вот собственно в палудисе то и интерес, вроде бы он поумнее портажа

Вообщем, в чем отличия от генту?

man diff

что там за формат пакетов? не могу найти

ebuild?

Пользуясь случаем хочу спросить - использует ли кто-то этот paludis?

Использую.

Как оно

Норм.

долго ли настраивать

Если в первый раз — да. Тот же поисковой индекс, например, да и просто alias'ы всякие.

много ли багов?

Последний раз был с сэндбоксом, когда вываливалась куча ворнингов, потому что гентушники сами не следуют своим спецификациям (ну, по словам юзеров или мейнтейнеров paludis'а, я в истории особо не разбирался, поэтому лучше меня про неё не спрашивать, я тупо дождался багфикса). В остальном, вполне себе работает, разве что иногда странно выбирает предпочтения (у меня затупил на выборе между ffmpeg и libav, словно в виртуальном пакете он выбирает первый попавшийся, а не подходящий, пришлось libav маскировать, тогда дело пошло).

Есть ли реальный прирост в том же расчёте зависимостей?

Не заметил. По-моему, так же.

Не заметил. По-моему, так же.

А, ну тогда для меня особо нет смысла костылить замену. Большое спасибо за отзыв.

Есть ли реальный прирост в том же расчёте зависимостей?

Скорее наоборот.

Паладис можно и на генту накатить.

что там за формат пакетов? не могу найти

exheres

пробовал как то, у меня не взлетел. Но это скорее из-за меня, ибо мне было вламы сильно с ним разбираться.

$ eix paludis
* sys-apps/paludis
     Available versions:  (~)1.2.0 (~)1.4.0 (~)1.4.2-r1 (~)2.0.0 {doc pbins pink portage prebuilt-documentation python python-bindings ruby ruby-bindings search-index test vim-syntax visibility xml zsh-completion PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7"}
     Homepage:            http://paludis.exherbo.org/
     Description:         paludis, the other package mangler

Что мешает просто поставить палудис?

Перед вами живой пользователь exherbo.

Сильно нравится community (как gentoo в самом начале), формат exheres (почти все часто повторяющиеся паттерны отрефакторены в exlibs - аналог eclass), так что часто exheres состоит из нескольких строчек - require sourceforge [[ suffix = tar.gz ]]. Все пакеты разбиты на оверлеи - perl, python, gnome, scientific, games, и т.д., что делает участие в разработке удобней (абсолютно все хранится в git репозиториях).

Вообще, каждый пользователь становится разработчиком, т.к. очень просто отправлять патчи - просто пушить свои коммиты в репозитории через Gerrit: https://galileo.mailstation.de/gerrit/. Оно там все ревьюится, собирается через Jenkins и мержится. Багзиллы толком нет, без патчей твои баги никому не интересны.

Нет, paludis не шустрей чем portage.

Если есть еще вопросы, отвечу.

Еще нравится полная поддержка multilib (почти все либы можно собрать в 32- и 64-битном варианте, без костылей вида emul-linux-**), в планах поддержка multiarch - пакеты можно будет прозрачно кросс-компилировать под разные target'ы - x86_64-pc-linux-gnu, i686-pc-linux-gnu, arm-linux-gnueabi-hf, что угодно. Фича сейчас в разработке, выглядит интересно: платформо-зависимые части пакетов (/usr/bin, /usr/lib) устанавливаются в /usr/{target} вместо /usr, например, в /usr/x86_64-pc-linux-gnu. Для совместимости делаются симлинки вида /usr/bin -> /usr/x86_64-pc-linux-gnu/bin. Систему можно установить хоть на ARM, поменяв профиль (симлинки начинают указывать на /usr/arm-linux-gnueabihf/bin). По-моему, достаточно инновационно.

У меня есть вопрос: почему ядро надо качать в обход пм, почему пакетом не сделали? Или нынче уже по-другому?

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

(openrc,

systemd

оверлеи,

есть. в отличие от генты, где оверлеи непонятно где, сколько и что там, и чувак от сохи (layman) ещё должен догадаться (для чего нужен отдельный wiki или README прямо в репозитории оверлея), в exherbo ВСЯ СИСТЕМА — ЭТО ОВЕРЛЕЙ.

потому что:
1. paludis, а не emerge.
2. рецепты сборки --exheres, а не ебилды
3. paludis «из коробки» умеет в репозитории, разных форматов, с разными приоритетами. можно маскировать/сортировать по отдельным репозиториям.
4. paludis почти из коробки, если немного допилить конфиг bashrc умеет в кросскомпиляцию. в Gentoo нужен cross-emerge, xmerge из crossdev. в Exherbo пользоваться кросскомплияцией ещё приятнее, потому что базовую систему разбили по ARCH, arch-machine как в gcc (x86-64-linux-...). такой multilib, multiarch практически из коробки
5. особая польза от 1, 2: cave search SUBJ выдаёт репозиторий, в котором искать SUBJ. есть репозитории unwritten и для не найденных. то есть, простым поиском из paludis/cave ты узнаешь: а) написал ли кто уже ебилд exheres-рецепт и если да, то где искать репозиторий. или ещё на написал, или собирался, да не написал.
6. из 1,2,3,5 вытекает: репозитории зависят друг от друга. то есть, в базовой системе минимум мусора (если ты не подключал ни одного вообще оверлея репозитория). забавно и automagically выглядит, когда ты говоришь ему cave resolve -x libreoffice -C .. (устранять зависимости от репозиториев автоматически) из голой системы, а он тебе подключает сам репозиторий X, Gnome (потому что gtk), java и т.п.

wiki),

идеология дистрибутива в духе Plan9, «лишнее ненужно ненужно». почитай оффсайт, ВСЕ ДОКИ, почитай оффсайт paludis, блоги планеты Exherbo, руководство по установке и по настройке systemd. в общем, документации не очень много по сравнению с гентой, потому что все базовые навыки (например, установка) точно такие же, как в Gentoo.

да, и irc-канал там очень дружелюбный. там сидят все основные разработчики, например kloepi, в целом идут на контакт и очень помогают (я ставил exherbo в VirtualBox, а там нету части драйверов под иксы из коробки, и инсталлятор тоже проверяет дистр и не ставится. поспрашивал на канале, потом в оффлайн на неделю, другими делами занимался. потом меня осенило — и написал себе ебыдло exheres.
в общем, очень дзенский дистрибутив — способствует внезапному просветлению :)))

формата ебилдов,

кури доки с оффсайта по Exheres. их надо прочитать все, да. отличий от ебыдла немного, возможностей и гибкости — больше.

ну и чего еще там...

тусуй на irc-канале, там помогут.

ну не знаю, мне вот интерес был в том, что при родной генте захотелось в винде попробовать Skribilo. оно под Guile, требует новой свежей, собирается под Cygwin с какими-то костылями, порты под cygwin устарели. в общем, проще в виртуалочку оказалось запилить полосатую корову, в неё — Guix (пакетный менеждер на базе Nix и Guile Scheme), им собрать Skribilo.
и потом уже, неторопливо почёсываясь ковырять порт под винду кроссплатформенным пакетным менеждером — то ли guix, то ли paludis (они оба умеют в кросскомпиляцию).

надо попробовать, а то на фанте скучно стало

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

<lurker-mode>свят-свят-свят... мне покамест локального оверлея хватает.. и кросскомпиляции под винду в mingw оверлей. </lurker-mode>

По-моему, достаточно инновационно.

да, с кросскомпиляцией в mingw оверлей под венду тут начинается веселуха. технически довольно прозрачно, но портировать по-нормальному всё довольно накладно. покамест иногда лень, и делаю ход конём — через guix или бинарные сборки.

cave import и такие вот бинарные пакеты — рулят, между прочим.

пытался портануть paludis под хайку и накатать репозиторий с портами под хайку, но в итоге подзабил с портированием — там в BSD системе у гаечки костыли, и надо линуксизмы переписывать на native API. порт собирается, но не работает, надо тщательнее тестировать, а толком некогда.

Багзиллы толком нет, без патчей твои баги никому не интересны.

Радикально, но не лишено смысла.

в планах поддержка multiarch
По-моему, достаточно инновационно.

Оно даже в протухшем ещё до релиза Debian Wheezy уже было готово.

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

нагляднее настройка груба, когда руками а не через особую гентушную магию.

При чем здесь «особая гентушная магия» к тому как это задумал и реализовал на практике аппстрим grub-а?

ну не знаю. я и на генте в грубе прописал симлинк на LastKnownGood ядро и initrd. а в какую-то утилиту, которая сама будет что-то там обновлять, то ли шибко умный genkernel, то ли grub2-update — я не верю.

почему ядро пакетом не сделали

Пакетом сделали linux-headers (чтобы можно было указать минимальную весрию). Само ядро я, например, тяну с linux-stable.git, удобней чем удалять/качать/распаковывать/собирать каждый раз новую версию, даже в полуавтоматическом режиме. Банально быстрей получается:

git pull && make oldconfig && make && sudo make install && grub-update

Оно даже в протухшем ещё до релиза Debian Wheezy уже было готово.

Сделать multiarch в роллинге немного сложнее - версии пакетов гвоздями не прибиты, а разруливать конфликты на системах пользователей - это хреновый план.

В Debian собрал срез с жестко-прибитыми зависимостями base-system - выложил пакеты и все дружно обновились(testing) ну и т.д. Тут так не взлетит.

grub2-update

Во-первых, grub2-mkconfig, а во-вторых, тебе никто не мешает выкинуть нахрен всё ненужное лично тебе из /etc/grub.d или обновлять конфиг граба руками. На любом дистре. Genkernel, если ему не указывать, сам в загрузчик не полезет.

версии пакетов гвоздями не прибиты

Ты так говоришь, будто в Debian зависимости задаются строгим равенством.

Радикально, но не лишено смысла.

Формально, bugzilla есть, но там никого нет, все тусуются на IRC канале, всегда есть кому пожаловаться/кого попинать.

в протухшем ещё до релиза Debian Wheezy уже было готово.

В бинарном дистре multiarch ИМХО лишен смысла, используется только разработчиками для удобной кросс-компиляции. Как я понимаю, для юзера различие только в доступности 32-битных библиотек на x86_64.

Ты так говоришь, будто в Debian зависимости задаются строгим равенством.

Для base-system в большем случае - да. То есть glibc ты отдельно не обновишь и не откатишь просто так.

Хотя откат glibc - это вообще так-себе идея.

Это удобно ровно до тех пор, пока не начинаешь использовать патченое ядро, не?

Особенно нагляден пример geek-sources в генте: довольно удобно подбирать набор патчей всего лишь юзами. Тут же получится прилично телодвижений для каждой новой версии ядра.

Для base-system в большем случае - да.

Почему-то я почти везде вижу «>=». Ограничения сверху и строгие равенства тоже бывают, но не так уж и часто. Я хз, конечно, что ты понимаешь под базовой системой в Debian (Required? Essential? Standard?), но вот пример зависимостей достаточно «системообразующего» gcc-4.9:

Depends: cpp-4.9 (= 4.9.0-7), gcc-4.9-base (= 4.9.0-7), binutils (>= 2.24.51.20140604), libgcc-4.9-dev (>= 4.9.0-7), libc6 (>= 2.14), libcloog-isl4 (>= 0.17), libgmp10 (>= 2:5.0.1~), libisl10 (>= 0.10), libmpc3, libmpfr4 (>= 3.1.2), zlib1g (>= 1:1.1.4)
Recommends: libc6-dev (>= 2.13-5)
Suggests: gcc-4.9-multilib, gcc-4.9-doc (>= 4.9), gcc-4.9-locales (>= 4.9), libgcc1-dbg (>= 1:4.9.0-7), libgomp1-dbg (>= 4.9.0-7), libitm1-dbg (>= 4.9.0-7), libatomic1-dbg (>= 4.9.0-7), libasan1-dbg (>= 4.9.0-7), liblsan0-dbg (>= 4.9.0-7), libtsan0-dbg (>= 4.9.0-7), libubsan0-dbg (>= 4.9.0-7), libvtv0-dbg (>= 4.9.0-7), libcilkrts5-dbg (>= 4.9.0-7), libquadmath0-dbg (>= 4.9.0-7), binutils-gold (>= 2.24.51.20140604)

а логические операторы есть? вроде libc6 (>= 2.11 and <= 2.15)

1) Патченые ядра не нужны

2) Патчи удобнее держать именно в виде гитовых веток. Можно мержить/ребейзить как угодно и не надо ждать пока это сделает мейнтейнер (привет init_6). Встроенные в git средства позволяют довести эти операции до автоматизма (иногда нужно будеть пользоваться mergetool).

Тогда ещё маленькая пачка вопросов, ответы на которые я так и не смог найти в своё время. Есть ли у палудиса аналог @module-rebuild или надо костылить? Можно ли в эксербо поменять компилятор, выкинуть gcc и вот это всё? Есть ли libcxx в репах?

Я правильно понимаю, что можно сделать мультилиб x86 и arm? Можно ли, например, часть приложений скомпилировать под x86, а часть под arm?

Использую паладис в генте, часто при обновлении мира зависимости не резолвятся, приходится прибегать к ручному вмешательству (не исключаю того, что у меня руки кривые). Такое случается в exherbo?

Мне гента нравится наличием огромного количества ебилдов. Можно ли использовать ебилды из дерева генты и гентовых оверлеев?

Точно не знаю, если честно. Вообще для этого есть поля «обратного» значения: Breaks, Conflicts. Вот официальный талмуд с описаниями: https://www.debian.org/doc/debian-policy/ch-relationships.html

достаточно «системообразующего» gcc-4.9:

gcc не слотирует только ленивый. Скажи лучше, часто в debian обновляют мажорную версию ОДНОГО системного компонента(glibc, binutils и т.д.). Или всё-таки тулчейн обновляют целиком, а когда нужно что-то в security сделать - бэкпортят?

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

Скажи лучше, часто в debian обновляют мажорную версию ОДНОГО системного компонента(glibc, binutils и т.д.).

Часто. Сколько сидел на тестинге, не помню, чтобы gcc обновлялся связкой с binutils или libc.

Можно мержить/ребейзить как угодно и не надо ждать пока это сделает мейнтейнер (привет init_6).

А я ВНЕЗАПНО никогда и ничего не мержил/ребейзил. Максимум что требуется от того кому нужно geek-sources это цифирьки версий под нужное ядро подобрать(в планах автоматизация этого процесса) да url-ы/репы проверить на доступность и актуальность.

аналог @module-rebuild

Нету и не будет. Вот, например, pkg_postinst для virtualbox-bin:

pkg_postinst() {
    ewarn "This exheres does not build the kernel modules for VirtualBox, you will have to do this"
    ewarn "on your own. The source code has been installed to /usr/src/${PNV}"
}

поменять компилятор

Exherbo не для извращений с системой. Идея в том, чтобы перевести все на апстрим. Все пакеты по возможности ванильные, сторонные патчи принимаются только если известен их статус, например, [merged in git version], или [упоротый апстрим]. Поэтому и нет проблем с пакетами - по умолчанию это проблемы апстрима.

llvm/clang есть, но нет возможности выбрать основным.

Вообще, есть dkms.

Не очень понимаю, как оно работает, т.к. никогда им не пользовался, но, если мне память не изменяет, оно работает не само по себе, модули на него натаскивать надо, нет? В Exherbo для приведённого вами же virtualbox-bin есть стандартное решение хотя бы с dkms или руками делать придётся?

Exherbo не для извращений с системой.

Т.е. слепить что-то нестандартное можно только с помощью жутких хаков? Весьма печально.

мультилиб x86 и arm

Теоретически, можно. Сейчас multiarch еще сырой, мне не удалось мигрировать на него (несовместим с multilib конфигурациями). Есть люди, которые уже используют, выкладывают stages. Воть больше информации: раз, два.

зависимости не резолвятся

Ни разу не было. При глобальном изменении use флагов случаются circural dependencies, но это и генте так же. Иногда разработчики начинают что-то глобально менять, надо просто подождать недельку и не синхронизироваться (или наоборот, помочь с расгребанием зависимостей :)). Последний раз, в ноябре меняли api в python.exlib, половина питонопакетов отвалилась: Python changes. Зато теперь есть мультипитон и мультируби (просто указываю PYTHON_ABIS="2.7 3.4", RUBY_ABIS="2.0 2.1").

использовать ебилды из дерева генты

Нет, они (намеренно?) поменяли все, например SRC_URI на DOWNLOADS, efunctions работают немножко по-другому. Если знать тонкости, не составляет труда переписать ebuild на exheres. Большинство так и становятся разработчиками :)

Лепить что-то нестандартное всегда можно, вопрос в том что тебе никто помогать с этим не будет, и, скорее всего, это не будет нужно никому кроме тебя.

Из манифеста

And no, we don't want to use Exherbo to implement your pet project. Especially not if it's a stupid pet project. Go and inflict it upon Gentoo, they think that porting ebuilds to run on SunOS 2 ksh under Cygwin is a great idea.

The above paragraph does not apply if your pet project is something we find interesting.

In Conclusion

It's not that we hate you (unless we do). It's just that we have nothing to offer you, and you have nothing to offer us.

Ну ты как тестируешь совместимость разных патчей? Ведь можно все разнести по гитовых ветках и скриптом проверять, мержится ли одна в другую с заданной стратегией (fast-forward, recursive).

В exherbo systemd по дефолту, сообщество меньше.

Ну ок. Значит им это проще, вдобавок разработчики могут иметь старую версию тулчейна для других утилит. В Gentoo такое не катит - если последний stable-тулчейн не может собрать что-то из stable - это косяк.

А апстрим далеко не везде резвый.

Ну ты как тестируешь совместимость разных патчей?

Я никакую "совместимость разных патчей" не тестирую.

Мало того мне на эту твою "совместимость" вообще плевать с высокой колокольни.

Ты меня перепутал с post-factum вот он да он всё что ты описываешь делает.

А в geek-sourses есть множество патчей и наборов патчей и кроме элементарных проверок на наличие файлов есть один единственный действительно значимый «тест» это patch --dry-run <patch_name> и любой патч перед применением либо проходит его либо нет. Кроме этого дан инструмент для изменения порядка в котором применяются патчи он позволяет самостоятельно расставлять свои собственные „приоритеты“ так как их видит любой пользователь. Вот именно поэтому geek-sourses вообще плевать и на количество патчей и на качество патчей (см переменную crap_patch=will_not_pass ).

Спасибо за разъяснение, действительно перепутал с pf-kernel.

Спасибо за разъяснение, действительно перепутал с pf-kernel.

Не за что.

А в вопросе "проверок совместимости" сперва надо понять одну простую штуку - она не остается величиной постоянной во времени для некоего неизменного множества разных версий патчей для соответствующих версий ядра. Вчера этот набор патчей был несовместим сегодня он будет совместим а завтра опять внесут такие изменения что он снова станет несовместим.

В некоторых версиях geek-sourses в зависимости от выбора USE флагов число патчей может превышать две тысячи и это без учета «патчей пользователя» которые тоже есть в общем котле.