[devel] Re: Обзор ситуации с разработкой Сизифа

Michael Shigorin =?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Вт Авг 30 22:24:36 MSD 2005


On Tue, Aug 30, 2005 at 09:15:13PM +0400, Alexey Tourbin wrote:
> > > Это всё чисто экономия трафика/машинных ресурсов.
> > > Стратегически не актуально.
> > Стратегически у меня есть свои соображения.
> Выдавай!  "Развитие проекта Sisyphus".  Здесь самое место,
> хотя и оффтопик. :)
         ^^^^^^^^
Что выдал, по тому ты уже сказал. :)

> RPMS.media представляется мне чисто технической проблемой --
> зарубать пакеты в отдельный каталог по набору критериев.
> Думаю, что нужно предъявить критическую массу таких пакетов --
> как минимум десяток пакетов общим объемом с гигабайт.

Так минимум полстолько по факту и где-то ещё так же --
по причинам нежелания обострять проблему.

> > 1) линуксы все маргинальные;
> > 2) альт -- относительно (sic) mainstream linux distro;
> Угу, всё относительно.

Что и требовалось... :)

> > > Если уж добиваться совместимости, то с Red Hat/Fedora Core.
> > 1) они невкусные;
> То есть мы вкусные, а они невкусные.  specfile'ы у них
> некрасивые.  В спеках есть макрос %defattr, которого по уму
> быть не должно!  [Остапа понесло...]

Они без изюма.  Просто работает [если не подпрыгивать].
У маргиналов иначе, ну да это тема для smoke-room@ (+/-).

> > > Лучше не специфические, а более универсальные.
> > Я не знал, как выразить то, что тот же preview на основе rpm или
> > deb делать технически нерентабельно.  То, что они умеют,
> > противоположно тому, что надо.
> То есть нужно иметь возможность сделать preview собственно
> до установки пакета?

Хуже -- до получения понравившегося изображения полностью.
Не пакета, а одного изображения (это вполне может быть добрая
пара мегабайт для 1600x1200, соответственно если делать --
осмысленно максимум в двух "шаблонных" разрешениях, ещё
1024x768 IMHO; такой "bisize" в rpm тоже не ложится иначе
как тупой дубликацией).

> > > > > Откуда уверенность, что пакеты наболее объемные будут
> > > > > наименее специфичными по части сборки?
> > > > Из опыта сборки пакетов, о которых речь.
> > (в первую очередь _медийных_ -- wallpapers всякие :)
> То есть суть обсуждаемой проблемы сводится к тому, какую <...>
> поставить себе на desktop и как это реализовать технически
> наиболее грамотно.  И на этой почве предлагается сотрудничать с
> PLD.

Нет, это развитие разговора на тему "а вообще-то часть media
бессмысленно _паковать_".

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

> Нет, это что-то.  Может, у меня сегодня просто хорошее
> настроение (альтернативно, "плохое настроение").  Хочется
> писать в духе morozov на novosoft.

Пиши :-)

> Может, в этом и есть великая сермяжная правда?

Мне так не кажется. (то, что абьюзать будут любую технологию 
и сколь угодно благое начинание -- данность)

> > > OK, какие есть объективные предпосылки для сотрудничества с PLD?
> > Спеки (в т.ч. макросы).  Похожие :-)
> Не, уже не похожие.  Дело вот в чем.  У них патчи лежат
> отдельно от спеков, в каталоге SOURCES.

Погоди, у меня они тоже в SOURCES.  А спеки -- в SPECS.  Ы?

> Нужно для данного набора спеков выдернуть из cvs патчи.  Вчера
> этим занимался.  Значит делаем, грубо говоря, `rpm -bE
> *.spec |awk '/^Patch/{print$2}'` и потом `cd SOURCES && cvs
> update "этот список"`.
> Так вот, `rpm -bE` не работает.
> Unknown tag: %bcond_without      tests   # do not perform "make test"
> Так что применяем более изощрённую технику выдирания патчей.
> Пробуем сделать --define 'bcond_without() %nil' и т.д.

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

> > > > Если не нравится часть про "подумать с другими проектами,
> > > > что можно делать сообща" -- поясни.
> > > Блин.  Когда своих идей нет, чужие руки не помогут.
> > > Поясню позже. :)
> > Поясни.  Мне вот наоборот кажется -- что идей /слишком/
> > много, при этом недостаток рук из-за того, что часть из них
> > реализуется с нуля вместо применения существующих решений
> > довольно сильно ощутим.
> Грамотно реализовать идею может только носитель идеи.

Нет, конечно.

> Либо ему вокруг себя нужно создавать соответствующий
> микроклимат, тогда будет сотрудничество.  Если идея уже
> реализована, её нужно заимствовать.

Да, разумеется.

> Сотрудничество c PLD на уровне заимствования спеков доступно
> каждому.  Я регулярно смотрю, что там в SPECS происходит.

Я знаю минимум ещё двоих таких умных. :)

> Если им интересно смотреть на наши спеки -- всегда пожалуйста.
> Но объединение на уровне репозитариев представляется очень
> проблемным (а разговор об этом преждевременным).

Вот поэтому Виталик и упомянул самое простое.  На самом деле
и тут реверсивные грабли в том плане, что у них подход к rpm
changelog несколько специфический... но "от нас к ним" должно
втечь нормально. :)

> Ну так вот, нужно развивать проект интенсивно, а не
> экстенсивно.  А сотрудничать на подъёме, а не на спаде.
> А то декаданс какой-то получается.

В этой свистопляске _я_ уже не берусь говорить, где что...

> > Почитай вот эту страничку и найди десять отличий:
> > http://www.linux.kiev.ua/ru/devel/hosting/web/
> Там что-то про хостинг.

Это касательно сотрудничества по части "о, вышел Linux 2.6.13".
Шоб десяток людей в десятке LUG'ов, подвизавшийся лепить и
поддерживать lug site, не мучался каждый раз с каждым запоздалым
или наоборот -- 0hour анонсом, а мог втянуть к себе записи,
которые уже созданы, или расшарить по CMS то, что вбил. :)

> Для меня, увы, более актуальной проблемой является первичный
> доступ в интернет.

Увы.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/



Подробная информация о списке рассылки Devel