[devel] Re: emacs-gnus packages ?

[Michael Shigorin <mike@osdn.org.ua>]

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

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/

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