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

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

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

★★★★★

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

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

Спасают только контрибьюторы, которые способны на конструктивный и вежливый диалог. Которые могут прислать патч, выслушать в чём его недостатки и поправить их.

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

Pinkbyte ★★★★★
()

Ни в коем случае не хочу деморализовать ОПа, т.к. идеи интересные, но, Эй! ребята, остановитесь! Хватит делать форки, лучше вкладывайте усилия в развитие Gentoo.

Какая польза от этих exherbo, calculate, sabayon и funtoo с их 2.5 пользователями? Просуществуют, пока разработчику не надоест.

Из этих дистрибутивов в живую видел только Funtoo, понравилась система профилей. Уверен, что и в остальных дистрибутивах есть свои интересные особенности, но все это костыли и нахлебники над Gentoo. Собственная популярность предельно низкая, и пользы «родителю» не несет совершенно.

Я далек от кухни дистрибутивов, что мешает послать те же патчи CentOS'а и свои ebuild'ы в багзиллу?

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

всё что в @system ДОЛЖНО быть установлено при любой операции с пакетами. Потому что зависимости от @system в ебилдах не ставятся.

Так-так, а как узнать, что пакет из @system, и зависимость от него прописывать не надо? Еще, кстати, в самом eclass прописывают зависимости, например, kde-base.eclass, что для меня явилось откровением.

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

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

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

а как узнать, что пакет из @system, и зависимость от него прописывать не надо?

eix -# --system

Еще, кстати, в самом eclass прописывают зависимости, например, kde-base.eclass, что для меня явилось откровением.

Да, это распространенная практика. Например тот же cmake-utils eclass прописывает build-time зависимость от cmake(что логично).

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

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

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

Хватит делать форки, лучше вкладывайте усилия в развитие Gentoo.

Иногда проще форкнуть и сделать так как считаешь нужным чем объяснять целой толпе что „так как есть в некоторых местах не сильно хорошо“ или „оно нарушает философию самой gentoo“.

Я далек от кухни дистрибутивов, что мешает послать те же патчи CentOS'а и свои ebuild'ы в багзиллу?

А вот как немного приблизишься к этой самой кухне то поймёшь больше. И потом про разницу в философиях я уже упоминал выше…

Персонально тебе ещё раз. В gentoo у каждого майнтрейнера есть свой набор ebuild-ов за которыми он, по идее, следит и они предпочитают тупо бампать их по любому поводу а в centos есть конкретная версия которую фиксят и доделывают, если это необходимо, короче говоря там эту версию поддерживают длительное время.

И в gentoo даже в ebuild-ах из stage-3 нет единства. epatch может быть в разных функциях. Разброд и шатания там дикие…

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

аа, это ж не distributed

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

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

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

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

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

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

всё что в @system ДОЛЖНО быть установлено при любой операции с пакетами

я бы сказал что это должно быть отключаемо

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

Это не философия - это о главном - о свободе. И о стабильности тоже.

Про свободу в gentoo расскажешь мне после того как будет отвязаны: bash, gcc, openrc из профиля. Т.е. когда появится та самая свобода в выборе того что именно использовать…

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

сюрприз сюрприза - но не все юзеры мантейнеры.

сюрприз сюрприз - зато все юзеры тестеры. А майнтрейнерами своего уютного локального оверлейчика все юзеры в конце концов тоже неизбежно становятся.

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

Funtoo

Ты не угадал. И почему она не нужна я уже несколько раз отвечал выше…

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

я бы сказал что это должно быть отключаемо

Отключаемо вообще много чего должно быть… Да вот сюрприз никому оно на поверку не надо. Примеров сколько угодно. Вон, в связи с недавними дырами, тот же bash. Да его можно не использовать, однако но это не значит что его в системе не будет вовсе. Это значит что будет bash и ещё что-то кроме него…

init_6 ★★★★★
() автор топика

может вернуться к истокам и запилить что-нидь вроде: DracoLinux (linux + pkgsrc)?

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

может вернуться к истокам и запилить что-нидь вроде: DracoLinux (linux + pkgsrc)?

Я пока-что ориентируюсь на portage. О pkgsrc я слышал но его не видел и не пробовал. Если оно действительно лучше portage мигрировать на него не проблема.

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

openrc - уже.

Подумать только. И для одного этого потребовалось (2014-2002=12) всего каких-то 12 лет!

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

тоесть в $(tree_dir)/profiles/base/packages включен bash вместо vitual/shell?

А никакого vitual/shell нет и в помине! Просто потому что не смотря на философию „модульности“ и „настраиваемости“ всем и так норм. «Дырявое? И чо? А ты его просто не используй.» - видимо логика какая-то такая.

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

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

Так вот как это делается. А мне интересно было как скастовать в тред кого-либо кроме «same here».

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

Про свободу в gentoo расскажешь мне после того как будет отвязаны: bash, gcc, openrc из профиля.

На счёт bash и gcc - яхз, но OpenRC я у себя выпилил с концами, так что думаю с башем и гцц тоже можно с напильником разобраться

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

но все равно не быстро

Т.е. альтернативы у openrc реально появились только 2,5 года назад а до этого в „модульной“ и „настраиваемой“ gentoo никому в голову не могло придти использовать что-то кроме него?

Ок. У меня тоже есть ссылка сырцы ChromeOS были в 2009-м и основан он на gentoo а использовал он upstart… ОЙ! :D И никому в голову не пришло взять их наработки в основное дерево?

ЗЫ И да ты прав на генту они переключились в 2010… В принципе не суть важно…

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

На счёт bash и gcc - яхз, но OpenRC я у себя выпилил с концами, так что думаю с башем и гцц тоже можно с напильником разобраться

При достаточном уровне владения напильником можно вообще многое… Я тоже целиком выпиливал openrc года полтора назад. Вопрос в другом почему для этого нужен напильник если изначально очевидно что если есть выбор из вариантов то должна быть и свобода выбора между этими вариантами.

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

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

Вообще, т.к. я не гентушник, но сочувствующий, у меня были мысли сделать наоборот. Внедрить USE-флаги в бинарный дистры, что бы получился гибридный дистрибутив или просто кастомный. Берем федору или центос, патчим rpm на предмет новых директив в spec-файлы типа %use, затем патчим yum(dnf) на предмет интеграции непосредственно с rpmbuild и mock - и получаем возможность собрать свой профиль.

Когда вышла новость про 21-федорино разделение на workstation/server/cloud - я грешным делом подумал сразу, что они что-то подобное вышеописанному внедрили. Но нет.

Базирование на генту скорее всего получится гибче и легче в реализации, более реально

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

Базирование на генту скорее всего получится гибче и легче в реализации, более реально

Вот сейчас на том, что осталось от моего ноута стоит centos. Да он в определенных моментах шикарен. Но по сравнению с gentoo это сущий ад. У меня своя локальная репа с уже собранным софтом которого мне не хватает.

# cat /etc/yum.repos.d/local.repo 
[local]
name=CentOS-$releasever - local packages for $basearch
baseurl=file:///share/CentOS/$releasever/local/$basearch
enabled=1
gpgcheck=0
protect=1

Так вот после обновлений и после выполненного createrepo уже с обновлениями yum в упор их не замечает до тех пор пока не будет заново пересоздан весь кеш всех реп. А в rpm в целом удобно только одно - если то как собраны пакеты в самом дистрибутиве вас устраивает и вам вообще ничего кроме этого не нужно.

До той гибкости которую даёт portage им очень далеко. Поэтому я и затеял гибрид. А centos был выбран намерено ещё и потому что поддержка у него длинная а свежий релиз только вышел.

init_6 ★★★★★
() автор топика

Я думал на счет проблемы плавающего релиза.

Сразу скажу, что, кроме основного компа, который обновляется каждый день, я еще «отвечаю» за 3 компа, которые находятся в разной степени досягаемости (как географической, так и по сети), и которые не обновляются впринципе. И когда оттуда приходят запросы вида «нужно установить XXX» (послений такой - обновить скайп), то так как последний sync происходил пару лет назад, то это превращяется в сущий ад: избранное скачивание e-build'ов, избранное обновление eclass, установка с --nodeps и другое шаманство. Как правило успешно, но времени занимает уйму.

С одной стороны, вроде как проблема решается просто зеркалированием ропозитория - такой себе срез. Но тогда мы лишаемся обновлений, что не всем по душе. Тогда мы приходим к идее замораживания веток - то есть зеркалирование и далее избранный sync. Проблема в том, что важно знать когда теряется принцип обратной совместимости для разных пакетов. Например, можно говорить, что все минорные версии питона 2.* совместимы, а 3.* не совместима с 2.* (AFAIK), но не факт что это работает со всем софтом. Кеды так вообще частенько ненароком ломают обратную совместимость - я говорю про конфиги в первую очередь. Отслеживание веток - сложнее, хоть и реализуемо.

Если разобраться с ветками, то получаем типа оверлей, который отождествляет собой релиз. Логично новый оверлей делать раз в пару лет. Но эта не еще одна гента, а просто оверлеи.

Я сам думаю над чем-то подобным. В предложенное втягиваться не готов, ибо 2 проблемы для меня отсутствуют (помойка и новый софт), а что касается последнего - нужен зравый концепт, который можно реализовать относительно несложно. Пока такой в голове не созрел (особенно что касается пункта «относительно несложно»).

Так что просто мысли вслух, может чем будет полезно.

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

Тогда мы приходим к идее замораживания веток - то есть зеркалирование и далее избранный sync

Коряво. Я решил эту проблему просто: если что нужно заморозить, то самописный скрипт копирует нужный ебилд в локальный репозиторий (у меня он называется «frozen»), выкачивает тарболлы с исходниками в отдельный DISTDIR, и маскирует все версии ниже и выше нужной.

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

Один единственный атом ни на что не влияет или перед установкой это всё-же нужно проверить?

Я маленько не в теме, но эту дурацкую проверку можно убрать? Я из-за этой фигни вот-вот заалиашу emerge на emerge -O.

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

«Дырявое? И чо? А ты его просто не используй.»

А если сделать rm /bin/bash && ln -s /bin/{z,ba}sh? zsh переходит в режим совместимости, если argv[0]==«bash», если что.

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

я бы сказал что это должно быть отключаемо

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

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

Не знаю — сейчас генты у меня нет, но вроде должно всё быть норм, т.к.

zsh переходит в режим совместимости, если argv[0]==«bash»

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

Примеров сколько угодно. Вон, в связи с недавними дырами, тот же bash.

Делать *.eclass портируемыми между различными шеллами — это садомазо, там же упороться можно. При том, что под шеллы нет вменяемых тулз для тест драйва.

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

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

Вон freebsd ещё c 2010го перешла на clang. Собирает оно половину или нет в данном случае вовсе не аргумент. А основная черта в том, что для того чтобы безболезненно использовать что угодно вместо gcc не делается вообще ничего. Собственно всё так-же как и было с openrc.

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

безболезненно использовать что угодно вместо gcc

Ещё раз: альтернативные компиляторы могут собрать хотя бы половину не то что дерева, а хотя бы половину десктопного софта? Или под безболезненным использованием ты подразумеваешщь печальное втыкание на вылетающую сборку?

Вон freebsd

При чём тут freebsd?

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

Я маленько не в теме, но эту дурацкую проверку можно убрать?

Да я тебе разрешаю её убрать. Где сырцы portage показать? :) А я на такие подвиги пока не готов.

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

Не знаю — сейчас генты у меня нет, но вроде должно всё быть норм, т.к.

„Костылерешение“ которое решает проблему дурацкими методами но не исправляет ситуацию целиком. К тому-же первопричину проблемы вообще не затрагивает.

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

Делать *.eclass портируемыми между различными шеллами — это садомазо, там же упороться можно. При том, что под шеллы нет вменяемых тулз для тест драйва.

Ищи в любимом поисковике по запросу „portage libbash“, удивляйся.

init_6 ★★★★★
() автор топика

имхо дело вы делаете правильное, только не так.

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

так зачем делать форк, при том что им будут пользоваться отсилы 1.5 землекопа, когда можно придти к gentoo'шникам и сказать смотрить как у меня все круто, давайте интегрироваться. в результате хорошо будет всем гентушникам(тада и респект и все такое).

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

где я не прав?

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

Ещё раз: альтернативные компиляторы могут собрать хотя бы половину не то что дерева, а хотя бы половину десктопного софта?

Ещё раз: целые операционные системы с десктопным софтом целиком переходят… а точнее говоря уже давно как перешли на clang. Это что не факт? Или его можно игнорировать ведь у нас есть gcc которого „хватит всем“?

При чём тут freebsd?

Ровно при том-же при чём и твоё „соберет половину“ или нет. И да к твоему сведению существует Gentoo/FreeBSD ага ты понял правильно там ядро не Linux а остальное gentoo.

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

целые операционные системы с десктопным софтом целиком переходят

Потому что патчат пакеты под нужные компиляторы. Внезапно, правда?

существует Gentoo/FreeBSD

И что - он тоже перешёл на цланг?

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

где я не прав?

Пока за исключением stage-3 мне показывать и нечего. Как остальное будет готово и работоспособно всё целиком там будет видно.

еще посмотрить в сторону http://www.funtoo.org

Сам смотри в её сторону. И да на этот вопрос я уже ответил неоднократно см ранее в этом топике. Но ещё и тебе могу повторить funtoo пустышка созданная только ради власти одного единственного человека.

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