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 тормоза уже неторт!. Пока-что разработка ведется в закрытом режиме одним единственным человеком.

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

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

★★★★★

Ответ на: комментарий от ZuBB

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

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

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

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

Об том и разговор.

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

перегнать дерево это только одна из подзадач. организуйтесь в команду, поговорите с Pinkbyte чтобы он был посредником(или ментором; ну или помог найти такого человека среди девелоперов) для выполнения всех подзадач из этой группы

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

перегнать дерево это только одна из подзадач. организуйтесь в команду, поговорите с Pinkbyte чтобы он был посредником(или ментором; ну или помог найти такого человека среди девелоперов) для выполнения всех подзадач из этой группы

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

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

беру свои слова назад.

ps: тред доставляет

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

даже всё дерево с историей им перегнал, но всем как всегда.

Там проблема не с репой(которая не быстро конвертится, но не суть). Там проблема с тем, что доступ к такой немаленькой репе достаточно тормозной в git-е. Свежий концепт mgorny о разделении репозитариев на history(дерево перегнанное в git, read-only), и dev(репозитарий, начинающийся с содержимого дерева последнего коммита из history, read-write) выглядит как минимум более жизнеспособным.

Подробности можно прочесть тут

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

которая не быстро конвертится, но не суть

5 часов на ноутбуке с core i7 и не самым быстрым хардом (всё в него упёрлось, да).

Там проблема с тем, что доступ к такой немаленькой репе достаточно тормозной в git-е.

Там - это где? Я уже два с половиной месяца держу /usr/portage в git и синкаюсь из того репозитария на гиториусе. Синкается быстрее чем через rsync, есличо.

Свежий концепт mgorny

Что, опять? Я от предыдущего со squashfs-diff ещё рыдать не перестал.

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

Я уже два с половиной месяца держу /usr/portage в git и синкаюсь из того репозитария на гиториусе. Синкается быстрее чем через rsync, есличо.

А я уже два с половиной месяца мержу снапшоты по emerge-webrsync. Синкается быстрее, чем через rsync, есличо :)

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

Я уже два с половиной месяца держу /usr/portage в git и синкаюсь из того репозитария на гиториусе. Синкается быстрее чем через rsync, есличо.

Если у тебя полная копия репозитария СО ВСЕЙ историей, не затруднит ли тебя показать выхлоп команды

time git status
Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Если у тебя полная копия репозитария СО ВСЕЙ историей

Нет конечно, я же не полный дебил. У меня shallow clone.

/usr/portage> time git status                                       
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	distfiles/
	metadata/md5-cache/

nothing added to commit but untracked files present (use "git add" to track)
git status  0.46s user 0.33s system 124% cpu 0.632 total
hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Нет конечно, я же не полный дебил. У меня shallow clone.

А теперь сделай обычный clone и посмотри сколько это займёт.

Hint: разработчикам НЕ ПОДХОДИТ shallow clone, потому что из него очень проблемно делать коммиты.

Переходить на git только для пользователей имеет смысл, ради ускорения синхронизации(как ты сам только что сказал). Но писать и отлаживать миграцию CVS в пользовательский git и соответствующие хуки... А потом писать еще раз миграцию уже для разработчиков... Это как-то хреново

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

А теперь сделай обычный clone и посмотри сколько это займёт.

/src/gentoo/gentoo-x86> git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
git status  2.15s user 1.93s system 113% cpu 4.085 total

Да, ты уменя убедил, 4 секунды - это долго.

Hint: разработчикам НЕ ПОДХОДИТ shallow clone, потому что из него очень проблемно делать коммиты.

Это починили в git 2.0, теперь проблем нет.

Но писать и отлаживать миграцию CVS в пользовательский git и соответствующие хуки...

Просто признай, что тебя покусали разработчики генты и ты теперь тоже ленивая задница. Если сходишь по той ссылке на гиториус, сможешь увидеть, что свежие апдейты из cvs приходят каждое утро. Запилить это было ни разу не сложно, поверь. Добавить пару хуков для подписи коммитов и прочего, думаю, тоже не составит труда. Только нафига, если можно просто выкинуть cvs и пользовать git?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Это починили в git 2.0, теперь проблем нет.

Есть, mgorny упоминал о том, что не во всех workflow это будет работать.

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

Ну конечно. Я запилил скрипт и он у меня работает, а то, что он не интегрируется с вашей инфраструктурой и его надо полностью переписать - это ваши проблемы, у меня всё работает - значит вы говно.

Нормальная позиция, Д'Артаньянская, чо, мне нравится.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

Есть, mgorny упоминал о том, что не во всех workflow это будет работать.

Он вообще много чего упоминал, он тот ещё затейник. Ссылку, пожалуйста, в студию.

Ну конечно. Я запилил скрипт и он у меня работает, а то, что он не интегрируется с вашей инфраструктурой и его надо полностью переписать - это ваши проблемы, у меня всё работает - значит вы говно.

Ты идиот? Я выше приводил ссылку на тред, в котором hasufell пишет, что практически никто даже не двигается в этом направлении и не пытается что-то сделать ввиду практически несуществующей координации между разработчиками, кучи волокиты и тому подобного рака. Разве что Патрег (вот этот http://gentooexperimental.org/~patrick/weblog/) экспериментировал с перегонкой дерева в git, но он использовал другие тулзы и у него всё получилось весьма хреново.

«Однажды лебедь, рак и щука задумали сыграть квартет. Поставил лебедь щуку раком, ... - а сыра нет.» - Это как раз про разработку Gentoo.

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

Это как раз про разработку Gentoo.

Я в разработке исповедаю просто принцип: «можешь сделать лучше - делай. Не можешь - не мешай другим». Патрик делает хоть что-то(при этом не всегда хорошо, но не ошибается тот кто ничего не делает). hasufell же последние 2 года только фиксит мелкие баги и истерит по большим проблемам. Причем истерит в режиме «у нас всё плохо!!!!111 Ок, что ты предлагаешь? Не знаю, но у нас всё плохо!!!!111» - конструктивизм от него просто прёт. mgorny выходит с иногда бредовыми(но когда ему объясняют - он понимает) но всё таки решениями.

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

Уже появился USE=git для sys-apps/portage или это (9999)?

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

Но писать и отлаживать миграцию CVS в пользовательский git и соответствующие хуки...

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

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

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

но есть вопрос по этому

там проблема с тем, что доступ к такой немаленькой репе достаточно тормозной в git-е

а как же с этим справляются другие проекты с большыми репами (например ядро)?

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

а как же с этим справляются другие проекты с большыми репами (например ядро)?

судя по этому:

pinkbyte@oas1 ~/dev/linux $ git remote -v
linux-next      git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (fetch)
linux-next      git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (push)
origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)
origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)
pinkbyte@oas1 ~/dev/linux $ time git status
On branch master
Your branch is behind 'origin/master' by 5057 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)


It took 5.23 seconds to enumerate untracked files. 'status -uno'
may speed it up, but you have to be careful not to forget to add
new files yourself (see 'git help status').
nothing to commit, working directory clean

real    0m24.609s
user    0m0.720s
sys     0m0.203s

никак :-/

И это при том, что master-ветка как правило содержит merge-коммиты от Линуса и прочих «проверенных людей».

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

Зависит от скорости сетевого соединения(то есть без сервера - печаль), в среднем не больше 2 секунд, но проблема тут в том, что git commit даже в оффлайн режиме займет еще больше времени. А когда надо сделать кучу мелких коммитов - это превращается в ад. CVS далеко не подарок(точнее наоборот - он окаменелое говно мамонта).

Если мы придержимся дизайна mgorny, среднее время коммита будет примерно такое же как и в cvs, только вот удобства будет на порядок больше.

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

аа, это ж не distributed

елки-палки. в дереве почти в 2.5 раза больше файлов чем в ядре (48к <> 119к)

бредо-мысли далее

1. недавно фб писал что перешли на ртуть и какой-то кастомный екстеншн ибо имеется та же проблема. никто туда не копал?

2. мож следует делить дерево на subrepos? все категории что не в @system - в подрепы. кому что нужто тот и подключает

ИМХО: то что для дев-репы нужно делать два этапа модификаций (по несколько подзадач в каждом) пока все придет в вид пригодный для пользователя говоритнамекает на то что эта система становится слишком сложной и ее нужно переосмыслить

ZuBB ★★★★★
()
Последнее исправление: ZuBB (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.