[devel] emacs-gnus packages ?

[devel] emacs-gnus packages ?

[Alex Ott]

Hi all

Тут делаю обновления пакетов для emacs и не знаю как правильно прописать
зависимости обнволения - раньше gnus собирался из поставки emacs, поэтому
он имел версию соответствующую emacs - 21.x. Теперь я собрал новую
стабильную версию - 5.10.6 и не знаю как правильно прописать obsoletes,
поскольку 5.10.6 меньше 21.3

посоветуйте как это сделать?

-- 
With best wishes, Alex Ott
-------------------------------
Jet Infosystems, Moscow, Russia    mailto: ottalex@narod.ru
http://xtalk.msk.su/~ott/          ICQ #22005116

[devel] Re: emacs-gnus packages ?

[Michael Shigorin]

[-- 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 --]

[devel] Epoch: %(date) (was Re: emacs-gnus packages ?)

[Mikhail Zabaluev]

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

Hello Michael,

On Mon, Jan 12, 2004 at 10:25:23AM +0200, Michael Shigorin wrote:
>
> Epoch: %(date +%%Y%%m%%d) ?

Вот эту практику я бы порекомендовал пресечь как порочную.
Это хоронит любые вменяемые зависимости по версиям.
Лучше оставьте последнюю дату в качестве эпохи и не меняйте её
без особой необходимости.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
It works the way the Wang did, what's the problem

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

[devel] Re: Epoch: %(date) (was Re: emacs-gnus packages ?)

[Michael Shigorin]

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

On Mon, Jan 12, 2004 at 01:04:47PM +0300, Mikhail Zabaluev wrote:
> > Epoch: %(date +%%Y%%m%%d) ?
> Вот эту практику я бы порекомендовал пресечь как порочную.

Порекомендуйте.  Но сперва обоснуйте.

> Это хоронит любые вменяемые зависимости по версиям.

Версиям _чего_?  Апстрима или сборки?

> Лучше оставьте последнюю дату в качестве эпохи и не меняйте её
> без особой необходимости.

Есть не просит.  Работает.  Что еще надо?  Плясать вокруг 
"1.0.0rc > 1.0.0" всяких?

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

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

[devel] Re: Epoch: %(date) (was Re: emacs-gnus packages ?)

[Mikhail Zabaluev]

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

Hello Michael,

On Mon, Jan 12, 2004 at 01:37:10PM +0200, Michael Shigorin wrote:
>
> On Mon, Jan 12, 2004 at 01:04:47PM +0300, Mikhail Zabaluev wrote:
> > > Epoch: %(date +%%Y%%m%%d) ?
> > Вот эту практику я бы порекомендовал пресечь как порочную.
> > Это хоронит любые вменяемые зависимости по версиям.
> 
> Версиям _чего_?  Апстрима или сборки?

Upstream. Кстати, эпохи сборки тоже проще запоминать по однозначным
номерам.

> > Лучше оставьте последнюю дату в качестве эпохи и не меняйте её
> > без особой необходимости.
> 
> Есть не просит.  Работает.  Что еще надо?  Плясать вокруг 
> "1.0.0rc > 1.0.0" всяких?

Для этого есть своя policy -- оформлять всякие rc в релизе:
alt0.1.rc2

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
You never gain something but that you lose something.
		-- Thoreau

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

[devel] Re: Epoch: %(date) (was Re: emacs-gnus packages ?)

[Michael Shigorin]

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

On Tue, Jan 13, 2004 at 01:34:50AM +0300, Mikhail Zabaluev wrote:
> > > > Epoch: %(date +%%Y%%m%%d) ?
> > > Вот эту практику я бы порекомендовал пресечь как порочную.
> > > Это хоронит любые вменяемые зависимости по версиям.
> > Версиям _чего_?  Апстрима или сборки?
> Upstream.  Кстати, эпохи сборки тоже проще запоминать по
> однозначным номерам.

For whom how.  Запоминать 100 персональных систем отсчета не
представляется возможным.  Даже 20+.

> > > Лучше оставьте последнюю дату в качестве эпохи и не меняйте её
> > > без особой необходимости.
> > Есть не просит.  Работает.  Что еще надо?  Плясать вокруг 
> > "1.0.0rc > 1.0.0" всяких?
> Для этого есть своя policy -- оформлять всякие rc в релизе:
> alt0.1.rc2

Вон посмотрите hddtemp мой -- как изворачивался под 0.x-betaX. 
С betaXX -- сдался.

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

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

[devel] Re: Epoch: %(date) (was Re: emacs-gnus packages ?)

[Mikhail Zabaluev]

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

Hello Michael,

On Wed, Jan 14, 2004 at 02:35:25PM +0200, Michael Shigorin wrote:
>
> > > Что еще надо?  Плясать вокруг 
> > > "1.0.0rc > 1.0.0" всяких?
> > Для этого есть своя policy -- оформлять всякие rc в релизе:
> > alt0.1.rc2
> 
> Вон посмотрите hddtemp мой -- как изворачивался под 0.x-betaX. 
> С betaXX -- сдался.

Что, проблема обновить номер своего релиза, который стоит _перед_
суффиксом beta (0.x-alt0.y.betaXX)?

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
If you can't understand it, it is intuitively obvious.

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

[devel] Re: Epoch: %(date) (was Re: emacs-gnus packages ?)

[Michael Shigorin]

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

On Fri, Jan 16, 2004 at 12:46:08AM +0300, Mikhail Zabaluev wrote:
> > Вон посмотрите hddtemp мой -- как изворачивался под
> > 0.x-betaX.  С betaXX -- сдался.
> Что, проблема обновить номер своего релиза, который стоит
> _перед_ суффиксом beta (0.x-alt0.y.betaXX)?

Да, проблема.  Меня убивают такие монстроидальные %release.
А политики дистрибутива по этой части в зафиксированном виде нет.

Посему.

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

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

[devel] Re: Epoch: %(date) (was Re: emacs-gnus packages ?)

[Mikhail Zabaluev]

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

Hello Michael,

On Fri, Jan 16, 2004 at 08:59:41AM +0200, Michael Shigorin wrote:
>
> On Fri, Jan 16, 2004 at 12:46:08AM +0300, Mikhail Zabaluev wrote:
> > > Вон посмотрите hddtemp мой -- как изворачивался под
> > > 0.x-betaX.  С betaXX -- сдался.
> > Что, проблема обновить номер своего релиза, который стоит
> > _перед_ суффиксом beta (0.x-alt0.y.betaXX)?
> 
> Да, проблема.  Меня убивают такие монстроидальные %release.

Это чисто эстетическое соображение?
А монстроидальный номер эпохи, которая вообще-то была задумана,
чтобы выходить из положения в сложных случаях (необходимость
понижения номера версии, смена схемы нумерации версий и т.п.),
реально нужна дай бог в 5% пакетов и еще в 5% является результатом
некомпетентности maintainer'а (Вашу практику я не имею в виду --
это скорее результат лени :)), никого не убивает?
Release как помойка хорош тем, что это самая низкоприоритетная
часть версии пакета при сравнении. Epoch, наоборот, имеет высший
приоритет. Если вы его постоянно увеличиваете, это мешает отслеживать
зависимости по версиям более тонко.

> А политики дистрибутива по этой части в зафиксированном виде нет.

Значит, надо её зафиксировать.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
To believe your own thought, to believe that what is true for
you in your private heart is true for all men -- that is genius.
		-- Ralph Waldo Emerson

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

[devel] Re: Epoch: %(date) (was Re: emacs-gnus packages ?)

[Alexey Tourbin]

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

On Fri, Jan 16, 2004 at 01:07:00PM +0300, Mikhail Zabaluev wrote:
> Release как помойка хорош тем, что это самая низкоприоритетная
> часть версии пакета при сравнении. Epoch, наоборот, имеет высший
> приоритет. Если вы его постоянно увеличиваете, это мешает отслеживать
> зависимости по версиям более тонко.

Есть ещё одна проблема с serial/epoch.  Сейчас, если в Requires на
версию пакета serial не указан, то "подходит" любой serial.  Т.е. по
умолчанию serial не учитывается, его как бы нет, если он не указан явно.

В новой версии rpm (по словам ldv) serial будет учитываться всегда и по
умолчанию считаться равным 0.  Т.е. это ещё одни грабли.

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