Re: [devel] Build from gear

["Денис Смирнов" <mithraen@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 7657 bytes --]

On Sun, Oct 15, 2006 at 04:04:31PM +0400, Konstantin A. Lepikhov wrote:

>> Кто будет этим ключевым звеном, уход которого в отпуск блокирует всю
>> работу? vsu@ прямой доступ нужен, насколько я понимаю. Но также мне
>> кажется сомнительным что Сергей обрадуется _необходимости_ делать git
>> pull/push, на каждое _твое_ изменение.
>> Напоминаю что скоро сборка пакета в Сизиф кроме как через git будет невозможна.
>> Как минимум ты и vsu@ получается должны иметь доступ на запись.
KAL> это организационный вопрос, а не технический.

Из этого организационного вопроса следуют технические следствия, на
разрешения которых, если прогноз ldv@ сбудется, у нас чуть больше 2-х
недель.

>> feat/fix/... это совершенно самостоятельные пакеты. Которые, насколько я
>> понимаю, уходят в Сизиф в неизменном виде. Чем и отличаются от модулей.
KAL> возможно, но они бесполезны без ядер.

Я понимаю.

Но это не повод городить лишнюю сущность. Напоминаю -- kernel cvs через
две недели мертв, создается нечто новое. Будет ли это kernel cvs поверх
git, или мы будем на максимум использовать особенности вновь создаваемой
системы?

>> Кто контролировать будет? Ты готов лично проверять корректность каждой
>> моей сборки zaptel (особенно с учетом того что из меня ядерщик такой же
>> как балерина -- то бишь на редкость хреновый)? Видимость контроля хуже
>> отсутствия такового.
KAL> мне ее приходится проверять, как и сборки других модулей. Но как ты
KAL> правильно заметил, это поверхностная оценка.

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

Мало того, если ты сможешь это формализовать, я даже возьмусь за это.

>> Насколько я помню мы рассчитываем на сознательность мантейнера. Если он не
>> сознательный -- он идет лесом (в смысле ему перекрывают доступ к заливанию
>> ядреных пакетов). Если совсем несознательный... но на моей памяти
>> прецедентов с совсем несознательными не было.
>> Да, я понимаю что любой имеющий права на сборку модулей может подсунуть
>> руткит. Но я сомневаюсь что кто-то проводит вычитку кода всех
>> kernel-source-*.
KAL> vsu@ читает :)

Увы, думаю далеко не все :)

>> Вася Пупкин не имеет доступа в kernel cvs, но ему нужно собрать для себя
>> ядрышко с модулями. Ядрышко его сборки нужно ещё и Василисе Пупкиной, а
>> также нескольким их коллегам.
>> Что делать бум? Пущай варяться в своих песочницах, али как?
KAL> а чем васю не устраивает свой cvs репозиторий?

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

Скажем по другому -- сильно мой via26 кому-то помешал? Был он мне нужен --
жил. Потом тихонько сдох, потому что никому больше нужен не оказался.
Оказался бы -- жил бы дальше. Чем это плохо?

Да, я понимаю что в дистрибутив такие левые ядра класть нельзя. Но и ll26
твой загнулся, во многом из-за того что многие кто могли бы по чуть-чуть
помочь просто не имели доступа к kernel cvs.

>> У нас есть сейчас три "типа официальных" flavour -- std, wks, ovz. Но я не
>> понимаю почему следует _запрещать_ альтернативные сборки, если они кому-то
>> нужны.
KAL> а их никто не запрещает - если ты посмотришь повнимательнее в kernel cvs, там
KAL> много "заброшенных" сборок вроде rt26, которая вообще является чьим-то
KAL> выкидышем, т.к. у нее -headers непригодны для сборки -modules. Т.е.
KAL> препятствий нет, есть лень и отсутствие времени/людей.

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

>> radlinux тому хороший пример -- автор варится в собственном соку.
KAL> и автора это устраивает.

Автора -- да. Его пользователей -- нет. Точно тебе говорю.

>> Плюс совсем нелогично что в _одном_ репозитории у нас лежит все
>> околоядерное. Это нелогично.
KAL> можно сделать _один_ околоядерный репозиторий, как в ovz.

Смысл?

>> Плюс нет разграничения зон ответственности. Вот я сейчас каааак возьму, и
>> кааааак сделаю коммит в wks26-*. Не, ну понятно что ты увидишь в почте cvs
>> log, дашь мне в лоб больно и откатишь изменение. А ежели не заметишь? ;)
KAL> замечу ;)

:)

>> Ну и самое главное что ты полностью проигнорировал. У нас нет SRPM. Вернее
>> через месяц не будет. Вообще не будет. И сделаный из kernel cvs/git/что
>> угодно ещё srpm ты сможешь только собрать локально и любоваться.
>> Поэтому подразумевается что из spec'а rpm генерируется исключительно на
>> git.altlinux.ru (кроме периода локального тестирования). И сделать всю
>> систему стоило бы так, чтобы это было удобно.
KAL> скрипты в kernel cvs не сильно завязаны на srpms. Точнее, вообще на них не
KAL> завязаны. Они завязаны на _сборочную среду_.

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

>> Это я к слову. Себе я велосипед из стайки скриптов изобрел, он работает,
>> это все страшно до жути но мне пофиг. И будет пофиг пока
>> asterisk*/seirospbx* означает что мантейнер я. Как только появится хотя бы
>> один модуль, который кому-то нужен, а мне нафиг не нужен, собирать его
>> геморройно, и я пошлю его мантейнера разбираться самого -- у него будут
>> проблемы.
KAL> потому что либо нет документации по сборке, либо система сборки
KAL> непрозрачна.

Нет. Это потому что как только я обновляю minor версию он должен обновлять
свой пакет. 

>> С firefox проблемы есть уже сейчас.
KAL> они временные до выхода fx-3.0.

До этого ещё дожить надо.

>> С php, который ты ниже упомянул, вообще не проблемы а вилы. Перманентно
>> существенная часть модулей не собрана, и обновить php попросту невозможно.
>> О нем и не говорят даже, потому что без мата о нем говорить трудно, а мы
>> все-таки в приличном обществе. Однако факт есть факт -- он нужен. И мне,
>> который его ненавидит всей душлой -- тоже.
KAL> какие нужные модули не собраны в данный момент?

Вот сию секунду собрано все мне нужное. Однако за последние пол года более
половины времени php был неюзабелен в том числе по причине не собранности
модулей. И у меня есть подозрение что как только будет обновлен php, цирк
продолжится.

>> И, кстати, php уже напрашивается как минимум на 2 flavour -- обычный и
>> hardened (в связи с тем что zend optimizer с hardened, AFAIR, не
>> совместим, а вот люди его хотят из-за кривых поделий с закрытыми
>> исходниками).
KAL> там все хуже: zend API сменился при переходе с 4.3.10 на 4.4.0, поэтому
KAL> старые блобы и так уже давно в пролете.

Это отдельная тема. Факт необходимости двух сборок php со всем окружением
никак не отменяющая.

Собственно о чем мы флеймим сейчас?

Меня интересует поиск более универсального решения, которое облегчит жизнь
как ядерщикам, так и всем остальным имеющим аналогичные проблемы. Ясно что
для ядра нужна более сложная система.

Также мне кажется что можно на максимум использовать преимущества git.

Ты мне предлагаешь оставить все как есть и не париться, добавив ещё к
этому невозможность отправить любой ядреный пакет в Сизиф без
подтверждения человека-прокси, который будет единственным способным
отправить что-либо ядреное в сизиф, так?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<ab> AMike: мы боты! мы боты! мы боты не купили!


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]