[devel] Re: emacs-gnus packages ?
Michael Shigorin
=?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Пн Янв 12 11:25:23 MSK 2004
On Sun, Jan 11, 2004 at 09:36:38PM +0300, Alex Ott wrote:
> стабильную версию - 5.10.6 и не знаю как правильно прописать
> obsoletes, поскольку 5.10.6 меньше 21.3
Он дорастет до 21.x? :)
> посоветуйте как это сделать?
Там было переименование, что нужно делать Obsoletes:?
Возможно, хватит простого Epoch: %(date +%%Y%%m%%d) ?
Вот кусочки старого обсуждения по теме:
---
Date: Sat, 5 Oct 2002 08:46:55 +0400 (MSD)
From: Khimenko Victor <khim sch57 msk ru>
To: Michael Shigorin <mike osdn org ua>
Subject: Re: Fwd: Re: [devel] Q: apache_home и другие
[...]
Эээ... Либо я чего-то не понимаю, либо одно из двух. Это требование
находится в разделе "возможные причины отказа в доступе к Sisyphus для
пакета" - или если это не требования, то зачем они вообще нужны, а если
требования, то почему так ?
-- http://docs.altlinux.ru/alt/devel/apb.html --
Возможные причины отказа в доступе к Sisyphus для пакета
[skipped]
Избыточная информация в версии пакета (например, 1.2.3pre5) может
повредить корректному обновлению (1.2.3 до 1.2.3pre5, несмотря на то,
что 1.2.3 - это финальная версия). Переносите все дополнительные
сведения в номер сборки (например, alt0.1.pre5);
-- cut --
Да, именно такое требование было и в KSI-Linux'е 2.0 . Но когда это было !!!
С тех пор в rpm'е появилась полноценная поддержка версий пакетов,
зависящих от даты (то есть полностью версия пакета может выглядеть так:
35031125:2.5.105pre5ac8-alt5 и это будет меньше, чем 35031205:2.5.105-alt1).
> > Зачем решать проблему способом, который приводит к путанице,
> > когда уже давным давно придумано более простое решение этой
> > проблемы ? И зачем вообще нужен Serial ??? IMO он вообще только
> > ненужную путаницу создает.
>
> Конечно, создает. И крайне вреден. Но откатить пакет назад
> тогда, когда срочно нужно (по версии), а "плохой", но более новый
> -- уже попал в обращение -- иначе не получается :(
Еще раз. Описываю сценарий.
-- cut --
1 февраля 2003 года - создан дистрибутив 3.5
SuperPuper-0.9-alt3 (реальная версия 35030201:0.9-alt3)
2 февраля 2003 года - выпущен пакет обновлений и там - новый пакет
SuperPuper-10.23-alt105 (реальная версия 35030202:10.23-alt105)
3 февраля 2003 года - выяснили, что 10.23 - полное г;?:╧*!но и решили
откатить назад, пересобрав пакет из дистрибутива
SuperPuper-0.9-alt4 (реальная версия 35030203:10.23-alt105)
новый пакет без проблем ставится поверх обоих выпущенных ранее
выпущенный 10 января 2003 года экпериментальный пакет
SuperPuper-10.23-alt57 (ральная версия 36030110:10.23-alt57)
при этом не обновляется ни одним из этих обновлений - он уже в разработке
и к нему эти updates неприменимы, но те пакеты, которые в экспериментальной
версии не менялись спокойно update'атся из официальных updates
-- cut --
В какой момент и зачем мне нужен Serial ? Заметь, что 3 февраля я мог бы
собрать пакет С ТЕМ ЖЕ именем ИЗ ТОГО ЖЕ .spec-файла (вообще ничего не
меняя) и его бы установили без всяких проблем АВТОМАТИЧЕСКИ ! Пакет,
собранный позднее ставится поверх того, что собран ранее. Независимо от
версий. Да, для contrib'а, куда могут upload'ить кто ни попадя этот
подход не годится, но если у пакета есть maintainer, который осуществляет
окончательную сборку, то этот подход чреват наименьшим количеством ошибок
IMNSHO ...
> > P.S. Здесь 20 - пришло из версии 2.0 :-) Для версии 5.8 будет,
> > соответственно
> > -- cut --
> > Epoch: 58%(date +%%y%%m%%d)
> > -- cut --
> >
> > При этом пакеты из дистрибутива 5.8 считаются старее пакетов
> > дистрибутива 5.9, даже если они собраны позже - что обычно и
> > должно быть, так как в большинстве случаев там должны
> > появляться только security updates после выхода дистрибутива.
>
> В данном случае они попросту разделени "стенками" репозиториев --
> апдейты к различным веткам лежат строго отдельно.
>
Ммм... То есть даже если, скажем, crontab не затронут бурным процессом
разработки для него будут выходить два update'а: для релиза и для
Sisyphus'а ? Это, конечно, тоже вариант...
> Или это был просто пример? Но Epoch -- конструкция именно
> "релизоориентированная".
>
Epoch - то, чего вы под него подложите. И если под него подложить именно
ту строчку, что я написал, то он будет зависеть от даты сборки.
> > P.S. Здесь 20 - пришло из версии 2.0 :-) Для версии 5.8 будет,
> > соответственно
> > -- cut --
> > Epoch: 58%(date +%%y%%m%%d)
> > -- cut --
> >
> > При этом пакеты из дистрибутива 5.8 считаются старее пакетов
> > дистрибутива 5.9, даже если они собраны позже - что обычно и
> > должно быть, так как в большинстве случаев там должны
> > появляться только security updates после выхода дистрибутива.
>
> В данном случае они попросту разделени "стенками" репозиториев --
> апдейты к различным веткам лежат строго отдельно.
>
Ммм... То есть даже если, скажем, crontab не затронут бурным процессом
разработки для него будут выходить два update'а: для релиза и для
Sisyphus'а ? Это, конечно, тоже вариант...
> Или это был просто пример? Но Epoch -- конструкция именно
> "релизоориентированная".
>
Epoch - то, чего вы под него подложите. И если под него подложить именно
ту строчку, что я написал, то он будет зависеть от даты сборки.
Epoch - то, чего вы под него подложите. И если под него подложить именно
ту строчку, что я написал, то он будет зависеть от даты сборки.
> > При этом, конечно, номера версий программ играют только
> > информационную функцию, но ЗАЧЕМ нужно стремиться к тому, чтобы
> > именно их RPM использовал при сравнении пакетов ???
>
> Хм. Тут не скажу -- бо опыта разруливания версий в scope
> дистрибутивов (в смысле релизов) у меня нет (и пока не собираюсь
> его приобретать).
>
> Если вопросы существенны -- стоит задать их Диме Левину
> <ldv altlinux org>, но, в общем, упор делается не столько на
> "точки разрыва" -- дистрибутивы/релизы, сколько на "непрерывную
> функцию" -- Sisyphus.
>
Как раз для этого Epoch использовать очень удобно: можно 100 раз ходить
с версии 0.9 на 10.23 и обратно, накопить в номере сборки аж -alt10000 и
после окончательной пересборки "под релиз" иметь пакет SuperPuper-0.6-alt1 ,
который, тем не менее ЧЕСТНО будет ставится поверх всех предыдущих пакетов
и не будет иметь в .spec-файле "мусора" в виде какого-то дикого Serial ...
P.S. BTW кому будет нужна ваша "непрерывная функция" без "точек разрыва" ?
Почему многие не используют Debian ? Потому что там новинки ОЧЕНЬ долго
появляются в частности (это не единственная причина, но одна из важных).
Ядро 2.4 появилось в июле 2002 года, например. Когда об этом говорят с
любителем Debian'а он начинает писать кипятком и говорить "ну как же - в
unstable это было еще бог знает когда", на что ему резонно отвечают "на
CD это когда появилось? в июле 2002 года ? значит ядро 2.4 появилось в
Debian'е в июле 2002 года". Для "широкой публики" интересны ТОЛЬКО релизы.
--
---- WBR, Michael Shigorin <mike на altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20040112/4be49c58/attachment-0001.bin>
Подробная информация о списке рассылки Devel