Gentoo && Fedora

И в догонку такой вопрос: кто-нибудь тут серьёзно использует Fedora на серверах? Про ЛОР я знаю. Вроде у no-dashi она на серверах, или я ошибаюсь?

Вот если бы в Fedora был такой же мощный менеджер пакетов, как Portage в Gentoo, то получился бы Gentoo.

Вот если бы в Fedora был такой же мощный менеджер пакетов, как Portage в Gentoo, то получился бы Gentoo.

Получился бы Gentoo с очень большим сообществом разработчиков и пользователей, а так же спонсором в лице Red Hat =).

Дык разве пакетный менеджер важен? Поставил пакеты и забыл.

Дык разве пакетный менеджер важен? Поставил пакеты и забыл.

При подходе «поставил и забыл» - действительно не важен. А если надо накладывать собственные патчи, тестировать разные варианты сборки и т.п.? Тут то всякие deb'ы с rpm'ами и начинают сливать =).

>Дык разве пакетный менеджер важен? Поставил пакеты и забыл.

Это одна из важнейших вещей в дистрибутиве.

Что такого вкусного есть в Fedor'е, чего нет в Gentoo ?

исключительный мазохизм.

Что такого вкусного есть в Fedor'е, чего нет в Gentoo ?

Свежий софт, разные новые решения и т.п.. Gentoo сейчас развивается очень медленно.

>такой же мощный менеджер пакетов, как Portage в Gentoo

Это вонючее угрёбище на питоне ты называешь «мощный менеджер пакетов»? Да ты неадекватен:)

Свежий софт

Свежее 9999 ? :))

разные новые решения

Например

Gentoo сейчас развивается очень медленно.

профит ?

Свежее 9999 ? :))

В дереве портежей многого нет, из оверлеев многое нормально не собирается.

Например

sssd, 389 (Fedora Directory Server), FreeIPA. Можно конечно сказать, что это всё специфичные для Fedora разработки, но они на самом деле гвоздями к ней не прибиты. Кроме того, в Gentoo (и большинстве (или всех?) других дистрибутивов) аналогов нет.

профит ?

Ты наверное хотел сказать «пруфлинк?» =).

Это вонючее угрёбище на питоне ты называешь «мощный менеджер пакетов»?

Покажи другой дистрибутив где можно с помощью трёх команд стандартными средствами собрать и поставить в систему пакет с наложением собственного патча?

Да ты неадекватен:)

Да. У меня даже справка есть! =)

И ещё важный момент, который я считаю плюсом Gentoo: безрелизность. ИМХО лучше решать мелкие проблемы при регулярном обновлении, чем разруливать одну большую жопу при обновлении дистрибутива с одной версии на другую (например debian 4 -> 5).

>Это одна из важнейших вещей в дистрибутиве.

Ну ё моё. Поставить, удалить, обновить. Федора это умеет. Другое дело что работа не в этом то заключается...

> И ещё важный момент, который я считаю плюсом Gentoo: безрелизность. ИМХО лучше решать мелкие проблемы при регулярном обновлении, чем разруливать одну большую жопу при обновлении дистрибутива с одной версии на другую (например debian 4 -> 5).

Хоть я и на федоре, но с таким аргументом не соглаcен. Лучше уже решать ту большую жопу один раз, заранее к этому подготовившись и спланировав своё время, чем постоянно быть на стрёме во время этих регулярных обновлений, отрываясь от «попить пиваса».

Еще pacman хорош, удобен как и emerge.

В дереве портежей многого нет, из оверлеев многое нормально не собирается.

Согласен, но эта проблема решается с изучения devmanual.gentoo.org

Можно конечно сказать, что это всё специфичные для Fedora разработки

Неужели нельзя их портировать ?

Ты наверное хотел сказать «пруфлинк?» =).

Именно =))

funtoo.org - динамичнее и экспериментальнее, чем gentoo.

что-то не пойму...

 ставим сырцы
1. zypper si имя_пакета

 патчим
2. [ cd /usr/src/packages/SPECS/ ] && parch -p0 < мой_офигенный_патч

 собираем и ставим
3. rpmbuild -bb [-ba] /usr/src/packages/SPECS/имя_пакета.spec && \
rpm [-Uhv] -i /usr/src/packages/RPMS/{%my_arch}/мой_новый_пакет.rpm

и что тут неудобного/непонятного? по мне так только за то, что spec-а одна и содержит все инструкции для сборки (и зачастую ещё может содержать отдельные инструкции соответственно специфике целевого дистрибутива!), все прочие форматы пакетов надо предать анафеме и спалить в очищающем скверну пламени. может после этого хоть начнётся унификация имён пакетов и т.п.

Просидел на нем полгода и хочу сказать, что главное различие git portage, остальное достигается ~ веткой и layman'ом

openrc 0.5 там появился намного раньше, кроме того, что репозиторий в git, он всё-таки посвежее. Сейчас в новинках coreboot и т.п., когда оно появится в основной ветке генты, хз.

По моим ощущениям, более модерновый подход у Дробинса.

2. [ cd /usr/src/packages/SPECS/ ] && parch -p0 < мой_офигенный_патч

И много толку от патченья SPEC-файла? =)

>>такой же мощный менеджер пакетов, как Portage в Gentoo

Это вонючее угрёбище на питоне ты называешь «мощный менеджер пакетов»? Да ты неадекватен:)

А что «адекватные» люди считаюы менеджером пакетов ?

И много толку от патченья SPEC-файла? =)

вам прочесть лекцию о «правилах приличия» при модификации пакетов дистрибутива? или вы не понимаете, что суть rmp и есть spec-файл?

:%s/rmp/rpm/g

вам прочесть лекцию о «правилах приличия» при модификации пакетов дистрибутива? или вы не понимаете, что суть rmp и есть spec-файл?

Предлагаешь ради патчей, который я хочу наложить один раз только «на посмотреть» править SPEC-файл? Зачем? Всё равно после «посмотреть» будет взята новая комбинация патчей, опять «на посмотреть». Извини, но каждый раз изменять SPEC-файл - это просто маразм, при условии, что использоваться он будет всего один раз.

И кстати, можно ли при сборке RPM исходники брать сразу из какой-нибудь VCS?

И кстати, можно ли при сборке RPM исходники брать сразу из какой-нибудь VCS?

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

Предлагаешь ради патчей, который я хочу наложить один раз только «на посмотреть» править SPEC-файл? Зачем? Всё равно после «посмотреть» будет взята новая комбинация патчей, опять «на посмотреть». Извини, но каждый раз изменять SPEC-файл - это просто маразм, при условии, что использоваться он будет всего один раз.

я не понимаю сути ваших претензий, поскольку давно уже вышел из того периода, когда создание/модификация нужного мне лично софта шло бы «мимо» spec-а. по мне так это гораздо легче, чем париться «вручную».

раньше обновления были существенны, сейчас нет

кроме того, что репозиторий в git, он всё-таки посвежее

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

Сейчас в новинках coreboot

Какая версия ?

http://paste.pocoo.org/show/186805/

я не понимаю сути ваших претензий, поскольку давно уже вышел из того периода, когда создание/модификация нужного мне лично софта шло бы «мимо» spec-а. по мне так это гораздо легче, чем париться «вручную».

«Вручную» - это редактирование spec-файла. В gentoo установка пакета с наложением своего патча, как я уже выше говорил, занимает всего три команды. Если кто-то очень в танке - при этом пакет встаёт в систему как обычно, так что свалки как в слаке при ./configure && make && make install не образуется.

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

Можно ссылку на какое-нибудь хауту? Гугль выдаёт только костыльные скрипты, которые тянут исходники из VCS и генерируют SPEC-файл по какому-то шаблону. Такое я и сам могу нагородить, но это получится говнокостыль. Хотелось бы чтобы при

rpmbuild -ba some.spec

Брось это глюкало.

«Вручную» - это редактирование spec-файла.

вы или не привыкли к специфике rpm, или не понимаете, что единственное отличие в подготовке патчсета для генты и rpm в учёте специфики spec-файла. всё, что нужно - добавить патч в спек и «обговорить» условия его применения. imho - сам по себе патчсет из воздуха не берётся. и, jfyi (imho), не вижу принципиальных различий меж ебилдом и спеком - пресловутые «use-флаги»/(аналоги ессно) при желании прекрасно можно оговорить и для компиляции rpm-пакета

всё, что нужно - добавить патч в спек и «обговорить» условия его применения.

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

Можно ссылку на какое-нибудь хауту? Гугль выдаёт только костыльные скрипты, которые тянут исходники из VCS и генерируют SPEC-файл по какому-то шаблону. Такое я и сам могу нагородить, но это получится говнокостыль. Хотелось бы чтобы при ******* автоматически вытягивалась самая свежая версия из VCS, заворачивалась в src.rpm (именно эти только что скачанные исходники) и собирались бинарные пакеты...

легко. посмотри идею тут: http://download.opensuse.org/pub/opensuse/repositories/X11:/Enlightenment/Fedora_12/src/E16-20100214_r46173-7.1.src.rpm

после rpmbuild --rebuild E16-20100214_r46173-7.1.src.rpm и получишь current svn, готовый к установке. пакет мой, там много недоработок - можно, например, добавить смену версии (указывая текущую дату) при условии компиляции из svn, можно более красиво «разложить» по «циклам» %prep, %build и %install - и т.п.. пока (в данном проекте) мне это не нужно/(не критично).

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

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

легко. посмотри идею тут: http://download.opensuse.org/pub/opensuse/repositories/X11:/Enlightenment/Fedora_12/src/E16-20100214_r46173-7.1.src.rpm

Во, это уже интересно, спасибо.

после rpmbuild --rebuild E16-20100214_r46173-7.1.src.rpm и получишь current svn, готовый к установке. пакет мой, там много недоработок - можно, например, добавить смену версии (указывая текущую дату) при условии компиляции из svn, можно более красиво «разложить» по «циклам» %prep, %build и %install - и т.п.. пока (в данном проекте) мне это не нужно/(не критично).

А после этого создастся ли src.rpm со свежими исходниками?

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

cp /path/to.patch SOURCES/
vim SPECS/some.spec
rpmbuild -ba SPECS/some.spec
sudo rpm -Uhv RPMS/x86_64/some-1.2.3.rpm

vs

ebuild /usr/portage/some/app-1.2.3.ebuild prepare
patch -p0 -d /var/tmp/portage/some/app-1.2.3/work </path/to.patch
ebuild /usr/portage/some/app-1.2.3.ebuild qmerge

=)

А после этого создастся ли src.rpm со свежими исходниками?

«полную» сборку гарантирует rpmbuild -ba file.spec . если есть желание с изменением «сырцов» на current vcs в src.rpm - надо подправить spec (imho в %prep предусмотреть этот вариант было бы наиболее уместно). для экспериментов можно дрючить вот это:

http://download.opensuse.org/pub/opensuse/repositories/X11:/Enlightenment/openSUSE_11.2/src/libeina-ver-pre-svn-05-0-svn_20100214_r46173-11.1.src.rpm

либка маленькая и не требует вагона зависимостей.

> оть я и на федоре, но с таким аргументом не соглаcен.

Ну-ну, там тоже от плановых обновлений сюрпризов хватает. Только что поставилось ядро 2.6.32. + починили ath9k, - отвалился режим gl в mplayer (с новыми дровами nvidia), испоганили драйвер imon, причём lirc так и не удалось заставить работать.

> и что тут неудобного/непонятного? по мне так только за то, что spec-а одна и содержит все инструкции для сборки (и зачастую ещё может содержать отдельные инструкции соответственно специфике целевого дистрибутива!), все прочие форматы пакетов надо предать анафеме и спалить в очищающем скверну пламени. может после этого хоть начнётся унификация имён пакетов и т.п.

таки у тебя rpm головного мозга ))
одной строкой и без холиварных соплей

#apt-build install --rebuild name_pkg --patch you_patch