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 To: Michael Shigorin 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 > дистрибутивов (в смысле релизов) у меня нет (и пока не собираюсь > его приобретать). > > Если вопросы существенны -- стоит задать их Диме Левину > , но, в общем, упор делается не столько на > "точки разрыва" -- дистрибутивы/релизы, сколько на "непрерывную > функцию" -- 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 ------ Linux.Kiev http://www.linux.kiev.ua/