LINUX.ORG.RU

Форк gentoo

 


7

4

Я пилю форк gentoo и решил создать этот тред. Пусть он будет только трекером участников.

Все, кто пожелает поучаствовать в разработке форка gentoo просьба здесь отписаться и указать, в каком направлении вы могли-бы поучаствовать в проекте.

Далее проблемы gentoo и способы их решений как я их вижу.

В gentoo я люблю пакетный менеджер portage а меня лично, главным образом, не устраивает плавающий релиз благодаря которому в ней нет ни:

  • Стабильной системы которой реально можно пользоваться ( А то что есть в большинстве своём либо „дыряво“ либо всё равно требует нестабильных ebuild-ов для своей работы )
  • Самых свежих релизов софта ( И да в оверлеях есть даже 9999 которые зачастую тоже „тыква“ а „новые“ релизы есть но спустя порядочное время. )

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

Меня не устраивает основное дерево portage в gentoo (в дальнейшем „помойка“). Благодаря тому что „помойка“ хранится в CVS а распространяется посредством rsync пользователи получают всё и сразу. Однако именно из-за этого „помойка“ лишена всех прелестей git-а как-то: ветви, форки, коллективная разработка. В gentoo работа и без этого раздроблена по оверлеям т.е. на деле из-за старых методов хранения (CVS) в gentoo мы имеем дублирование кода („помойка“ и оверлеи) тогда как в git всё можно просто решить ветвями stable, unstable.

Почему „помойка“ это плохо? Потому-что подход всё и сразу в какой-то степени был оправдан. Однако так или иначе но помимо помойки всё равно существуют оверлеи (X11, gnome, kde…) и это факт. Напрашивается вывод: укрепить и развить модульность gentoo путем дробления одной большой „помойки“, в том виде в каком мы её имеем, на несколько оверлеев: base(исключительно содержимое stage3 с USE-флагами по умолчанию), X11, gnome, kde… примерно так, как это организовано в exherbo.

Вы всё равно при всём своём желании не сможете использовать абсолютно все ebuild-ы из „помойки“! Я гарантирую это!!! К тому-же как было выяснено эксперементальным путем (см Portage тормоза уже неторт!) „кастрирование“ „помойки“ до объёмов base ускоряет portage почти в 4-ре раза(если быть точным то в 3,875 раз) при прочих неизменных параметрах. Значит в результате деления мы получаем не только большую модульность и в целом упорядоченность но ещё и большую скорость вычислений у того-же самого portage.

В идеале если количество ebuild-ов в наших раздробленных оверлеях в сумме сравняется с количеством ebuild-ов в „помойке“ скорости тоже сравняются. Однако не стоит забывать что даже сейчас в „помойке“ предостаточно такого трешака который если кто-то и использует то это те самые полтора человека вместе с их майнтрейнером. Так вот избавление в процесее дробления „помойки“ на отдельные оверлеи от любого такого ненужного трешака есть очевидное благо.

Если не будет плавающих релизов то, безусловно, надо на что-то ориентироватся. Таким замечательным ориентиром, на мой взгляд, может выступать centos. Почему? Главным образом потому, что срок поддержки centos какие-то совершенно смешные 13 лет и совсем свежая centos-7 вышла только осенью этого 2014го года. И ещё потому что инженеры red-hat таки знают своё дело - к примеру если сравнить количество заплаток у python2 то в gentoo их около 5ти а в centos их более 50ти. Как говорится почувствуйте разницу.

base(исключительно содержимое stage3 с USE-флагами по умолчанию) с интегрированными патчами из centos у меня уже готов. Т.е. в данный момент свой собственный stage-{1,2,3} у меня уже есть и вы его можете отыскать пройдясь по ссылкам из Portage тормоза уже неторт!. Пока-что разработка ведется в закрытом режиме одним единственным человеком.

Эта тема для того-чтобы собрать заинтересованных в том-же.

Сообщайте потенциально заинтересованным гентушникам. А с трёпом про «ненужно» лучше сразу идите в толксы.

★★★★★

не устраивает плавающий релиз благодаря которому в ней нет ни

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

По сути твой форк должен заключаться в поддержке git дерева, которое более стабильно, чем гентушное.

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

Это никак не связано с плаванием релиза.

Это связано не в меньшей степени и с этим тоже.

init_6 ★★★★★ ()

Вы всё равно при всём своём желании не сможете использовать абсолютно все ebuild-ы из „помойки“!

Помойму както можно указать портеджу какие пакеты не нужно синкать.

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

Какую проблему и как решит фиксирование релиза?

vurdalak ★★★★★ ()

Я пилю форк gentoo и решил создать этот тред

Сколько часов в день ты отдаёшь этой работе?

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

Повторяю свой вопрос.

И самое главное

форк gentoo

Подразумевает, что ты берешь генту на данный момент как она есть, а дальше пилишь всё сам. Отчего-то у меня есть подозрение, что ты собрался паразитировать на теле генты, запиливая свои патчи/оверлеи. Нет?

no-such-file ★★★★★ ()
Ответ на: комментарий от TDrive

Помойму както можно указать портеджу какие пакеты не нужно синкать.

Да можно. Но это не решение изначальной проблемы а костыль.

init_6 ★★★★★ ()

А с трёпом про «ненужно» лучше сразу идите в толксы.

/me пошел в толксы.

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

Какую проблему и как решит фиксирование релиза?

Значительное время (13 лет) гарантированно будет стабильная система со степенью стабильности не хуже чем в centos.

init_6 ★★★★★ ()

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

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

„помойка“ хранится в CVS

В багзилле есть метабаг, в котором написаны проблемы, которые надо решить, для перехода на git. Я тебе даже скажу по секрету, что portage давно умеет работать с git, если находит каталог .git в /usr/portage. Можешь для примера грохнуть /usr/portage и сделать git-clone с funtoo (или как его там). Медленно, но портаж переползёт на git. Но тут возникнет другая проблема: гит мало скачивает, когда обновляешься часто. А если давно не обновлялся, то rsync куда быстрее.

По тормозам ничего сказать не могу, конечно долго расчет зависимостей идёт, но не то чтобы смертельно.

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

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

Вся суть сообщества:
-Эх, скорее бы вендекапец. Ну или игорей завезите!
-О, я знаю, что нам надо сделать, давайте запилим ни с чем не совместимый форк!

Valkeru ★★★★ ()

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

Deleted ()

Разбить дерево - идея интересная, но тут можно использовать разные подходы. Можно добавить блокировку обработки каких-либо сегментов дерева. Пример «от балды»:

dev-php/* kde-*/* gnome-base/*keyring

Ну и переписать portage на C для пущей скорости, всё равно его перелопачивать придётся.

Bfgeshka ★★★★★ ()
Ответ на: комментарий от no-such-file

Сколько часов в день ты отдаёшь этой работе?

От начала до stage3 у меня заняло по паре часов в день в течение недели и с учетом того, что большую часть времени у меня не было то света то связи.

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

Я не Даниэлька. Но да с чего то нужно начинать и если использование снапшота portge как основы по твоему это „паразитирование“ то да я паразитировал. А дальше меня gentoo не будет интересовать и, если её самой это не будет нужно, то и никакой обратной отдачи в gentoo я делать не собираюсь.

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

По сути твой форк должен заключаться в поддержке git дерева, которое более стабильно, чем гентушное.

Ну, так Funtoo же.

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

Это ты написал, чего тебе хочется достичь. А я спрашиваю, как ты этого собираешься достичь. Т.е. я пытаюсь получить не ответ «я сделаю всем хорошо, и всем будет хорошо», а «я изменю то-то вот так-то, это решит проблему такую-то, и всем будет хорошо».

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

Значительное время (13 лет) гарантированно будет стабильная система со степенью стабильности не хуже чем в centos.

Как ты собираешься это обеспечить, если в дереве уже полно ebuild'ов, для которых отсутствуют тарболлы?

anonymous ()
Ответ на: комментарий от xorik

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

Да улучшится - в багзилле будут висеть фиксы… месяцами и годами… А потому-что майнтрейнеры в большинстве ещё и руководствуются велением своей левой пятки а не здравым смыслом и философией gentoo.

Я тебе даже скажу по секрету, что portage давно умеет работать с git, если находит каталог .git в /usr/portage.

Спасибо капитан я в курсе.

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

Но да с чего то нужно начинать и если использование снапшота portge как основы по твоему это „паразитирование“ то да я паразитировал. А дальше меня gentoo не будет интересовать и, если её самой это не будет нужно, то и никакой обратной отдачи в gentoo я делать не собираюсь.

Использование гентушных eclass, от которых тебе не удастся отказаться, не паразитирование?

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

Ну, так Funtoo же.

Цели не ясны, задачи не определены. Одно понятно оно нужно было Даниэльке что-бы командовать.

init_6 ★★★★★ ()

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

Может, пора уже заменить кривой портейдж на pkgcore?

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

А я спрашиваю, как ты этого собираешься достичь.

Как? Гибрид gentoo и centos. Детали реализации см первый пост.

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

Как ты собираешься это обеспечить, если в дереве уже полно ebuild'ов, для которых отсутствуют тарболлы?

Уважаемый тарболлы есть даже для самых старых снапшотов gentoo.

init_6 ★★★★★ ()

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

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

Нет, ты не описал детали реализации. В данный момент у генты проблема с поддержкой дерева, потому что не хватает мейнтейнеров. Как ты это решаешь? Автоматизация поиска багов, автоматическое тестирование всех возможных комбинаций пакетов?

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

Использование гентушных eclass, от которых тебе не удастся отказаться, не паразитирование?

Если это по твоему паразитирование то да. И да я нигде даже не заикался от полного отказа от portage или переписывании всего на мифические велосипеды на с/с++.

init_6 ★★★★★ ()

А я знаю как назвать! Я знаю! Initoo или init6oo!

Не за что.

LightDiver ★★★★★ ()
Ответ на: комментарий от quantum-troll

Может, пора уже заменить кривой портейдж на pkgcore?

Не кривой pkgcore поддерживает все eclass-ы/ebuild-ы/eapi-1,2,3,4,5 ? Если ответы да мне без разницы. Пока что меня устраивает portage.

init_6 ★★★★★ ()

Меня не устраивает основное дерево portage в gentoo (в дальнейшем „помойка“). Благодаря тому что „помойка“ хранится в CVS а распространяется посредством rsync пользователи получают всё и сразу. Однако именно из-за этого „помойка“ лишена всех прелестей git-а как-то: ветви, форки, коллективная разработка.

https://gitorious.org/gentoo-x86/gentoo-x86/

Можешь форкать сколько влезет.

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

поддерживает все eclass-ы/ebuild-ы/eapi-1,2,3,4,5

Вот из-за этого хлама все и начали на генту забивать.
Писать ебилды, сравнимые по размеру с БСЭ, мало кому хочется.

devl547 ★★★★★ ()

Практически всё, что ты описал - это проблема в организации. Частично это решено в Funtoo, и лучше бы ты к ним присоединился, т.к. у них весьма мало людских ресурсов.

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

Убей себя. Разрабатывать что-то под CentOS - это лютый ад. Как раз таки из-за ВЕЛИКОЙ ЗАМОРОЗКИ ВСЕГО СОФТА ВООБЩЕ, в результате чего приходится или возиться со сборкой всего самостоятельно, или, что ещё хуже, ориентироваться на библиотеки 5-летней давности.

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

В данный момент у генты проблема с поддержкой дерева, потому что не хватает мейнтейнеров. Как ты это решаешь?

Очевидно что закрепление майнтрейнеров за конкретными ebuild-ами и дублирование работы ещё и на оверлеи никак не способствуют тому чтобы рук хватало на все. К тому же результаты ещё и в том что в деревt разброд и шатания даже по таким вопросам как в какой функции выполнять epatch.

Если ebuild-ов будет меньше и за каждым из них не будет закреплен конкретный „вахтер“ ситуация будет несколько другая.

init_6 ★★★★★ ()

Вижу две проблемы

  • низкое качество или низкая скорость обновления ебилдов. лечится увеличением man power, которая работает над этой проблеммой. что делает автор? обратное.
  • низкая скорость работы portage. лечится поиском узких мест и исправлениями в этой программе или R&D новых реализаций portage. что делает автор? вместо решения проблеммы пытается уменьшить ее видимость добавляя новые ограничения в использовании дистра, изначально дающего широкую свободу выбора

с наилучшими пожеланиями
ваш врио майор Ясен Пень

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

Писать ебилды, сравнимые по размеру с БСЭ, мало кому хочется.

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

init_6 ★★★★★ ()

Да, сокращённый размер основного дерева - это здравая идея. Но со всем остальным я не согласен, особенно с фиксированными релизами.

pedobear ()
Ответ на: комментарий от devl547

Писать ебилды, сравнимые по размеру с БСЭ, мало кому хочется.

Чушь! Можешь писать все ручками econf/emake/doins — никто не запрещает. Кому удобнее специализированные eclass, использует их, что, как правило, сокращает код ебилда.

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

Не кривой pkgcore поддерживает все eclass-ы/ebuild-ы/eapi-1,2,3,4,5 ?

Тот, что 9999 — да. По-крайней мере у меня не возникало проблем с ними.
Единственное, с чем были проблемы, так это с libav и ffmpeg, так как их сборка вылазит за пределы рабочего каталога.

quantum-troll ★★★★★ ()
Ответ на: комментарий от iVS

Напомнить ответ Даниэльки на его старом и теперь уже удаленном форуме на негодующие темы юзеров десктопа в темах про то что в фанте просрали релизы gnome/kde которые уже давно есть в генте?

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

низкая скорость работы portage. лечится поиском узких мест и исправлениями в этой программе

Кто-нибудь может мне внятно объяснить, на кой хрен портеж каждый раз проводит всевозможные проверки дерева и всех установленных оверлеев? Pinkbyte, что скажешь?

pedobear ()

Благодаря тому что „помойка“ хранится в CVS а распространяется посредством rsync пользователи получают всё и сразу.

Однако именно из-за этого „помойка“ лишена всех прелестей git-а как-то: ветви, форки, коллективная разработка.

есть много времени? возьми и займись деломпомоги любимому дистру перейти на гит

ZuBB ★★★★★ ()
Ответ на: комментарий от quantum-troll

Тот, что 9999 — да. По-крайней мере у меня не возникало проблем с ними.

Пока что я делаю все под portage. Если с pkgcore всё действительно так замечательно то перейти на него никогда не поздно.

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

Очевидно что закрепление майнтрейнеров за конкретными ebuild-ами и дублирование работы ещё и на оверлеи никак не способствуют тому чтобы рук хватало на все.

Они способствуют качеству поддержки, жертвуя количеством. Ты предлагаешь сделать наоборот?

Если ebuild-ов будет меньше и за каждым из них не будет закреплен конкретный „вахтер“ ситуация будет несколько другая.

С чего это их станет меньше?

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

Да я и так знаю, что их десктоп не волнует, разве что кто-то из них пилит openbox. Это проблема малого числа майнтейнеров, очевидно. И пока фанту не работает настолько стабильно, насколько это возможно, на сервере, то поддержка еще и десктопа — только разбазаривание людских ресурсов. А людей у них — пшик.

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

есть много времени? возьми и займись деломпомоги любимому дистру перейти на гит

А я не вижу в этом смысла. Целиком на git Даниэлька уже перевел свою фанту а в gentoo это будет буксовать ещё очень долго потому что бюрократия.

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

есть много времени? возьми и займись деломпомоги любимому дистру перейти на гит

Тут ТС прав: это слегка бесполезно. Я уже пытался, даже всё дерево с историей им перегнал, но всем как всегда.

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