[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